AD-A247  274 


Hoiwiuniis  Ml  FOMX  MSPECiiM  MB  s»nv  ONia 


DTIC 

iELECTE 
MAR  0  3 1992 


SYSTEM  SAFETY  HANDBOOK 
AFISC  SSH  1-1 


SOFTWARE  SYSTEM  SAFETY 


^his  dement  has  been  approved 
for  public  release  and  sale;  ita 
<3i!:»nb'.ifion  IS  unlimited 


5  SEPTEMBER  1985 


92-05025 


92  2  26  038 


Best 

Available 

Copy 


TABLE  OF  CONTENTS 


1.  PURPOSE . 1 

1.1  CONTRACT  APPLICATION  .  1 

2.  SCOPE . . 

2.1  ORGANIZATION  OF  THIS  HANDBOOK . 1 

3.  DEFINITIONS  .  1 

4.  INTRODUCTION  .  3 

4.1  THE  SOFTWARE  HAZARD . 4 

4.2  MANAGEMENT  CONSIDERATIONS  .  4 

5.  DESIGN  GUIDELINES  FOR  SOFTWARE  SYSTEM  SAFETY  .  5 

5.1  SYSTEM  CONSIDERATIONS  .  5 

5.2  HARDWARE  CONSIDERATIONS  FOR  SOFTWARE  SAFETY  .  6 

5.3  REQUIREMENTS  FOR  THE  VARIOUS  PHASES  OF  SYSTEM 

DEVELOPMENT  .  6 

5.3.1  Specification  Phase  .  7 

5.3.2  Design  Phase  .  7 

5.3.3  Coding  Phase . 7 

5.3.4  Testing  Phase . 7 

5.3.5  Deployment/Operational/Maintenance  Phase  .... 

6.  SOFTWARE  SAFETY  ANALYSIS  .  9 

6.1  PRELIMINARY  AND  FOLLOW-ON  SOFTWARE  HAZARD  ANALYSIS  ...  3 

6.1.1  Preliminary  Software  Hazard  Analysis  .  9 

6.1.2  Follow-on  Software  Hazard  Analysis  .  .  9 

7.  SOFTWARE  HAZARD  ANALYSIS  METHODOLOGIES  .  10 

7.1  SOFTWARE  FAULT  TREE  (SOFT  TREE)  . 10 

7.2  SOFTWARE  SNEAK  CIRCUIT  ANALYSIS  .  12 

7.3  NUCLEAR  SAFETY  CROSS-CHECK  ANALYSIS  (NSCCA)  .  14 

7.4  SAFETY  ANALYSIS  USING  PETRI  NETS  .  17 

8.  SOFTWARE  SYSTEM  SAFETY  DESIGN  RULES  AND  GUIDELINES  .  20 

APPENDICES . 25 

APPENDIX  A.  SOFTWARE  SAFETY  ANALYSIS  SPECIFICATION  -  EXAMPLE  .  .  26 

APPENDIX  B.  REQUEST  FOR  PROPOSAL  EXAMPLE  .  29 

APPENDIX  C.  STATEMENT  OF  WORK  EXAMPLE . 36 


No  ot  Printed  Pages:  41 
OPR:  SESD 

Approved  by:  Col  Paul  D.  Smith 
Editor:  Ellyn  Eisenbeisz 

DISTRIBUTION:  X 


Accesion  For 

NTIS  CRA&I 
DTIC  TAti 
Ui’.£i.if:otj::ced 
Juslificdt.'on 


By 

Distabution  / 


Availab'!!*'/  C' 


Dist  i 


f\-\ 


»  • 


Department  of  the  Air  Force 

Headquarters  Air  Force  Inspection  and  Safety  Center 
Norton  Air  Force  Base,  California  92409-7001 


AFISC  SSH  1-1 
5  September  1985 


SOFTWARE  SYSTEM  SAFETY  HANDBOOK 


1.  PURPOSE 

The  priaary  purpose  of  this  handbook  Is  to 
docuMnt  technical  knowledge  of  safety  tech¬ 
niques  and  aethodologles  than  can  be  used  to 
support  acquisition  programs  which  Involve 
coaputer/embedded  computer  systems.  It  Is 
Intended  to  aid  In  the  development  of  'safe* 
system  software.  This  handbook  does  not  and 
will  not  describe  how  to  design  functional 
performance  Into  a  system.  Rather,  the  handbook 
does  and  will  continue  to  describe  design 
choice  limits,  boundary  values,  and  preferred 
practices  that  relate  to  maximizing  overall 
system  safety.  The  major  emphasis  of  this 
handbook  Is  to  provide  an  assist  In  specifying 
and  designing  for  system  safety.  The  section 
herein  that  provides  a  checklist  of  rules  and 
guidelines  Is  aimed  at  the  up-front  and  top- 
down  design  principles.  A  later  section 
describing  verification  and  evaluation  tech¬ 
niques  Is  aimed  at  picking  up  where  specifica¬ 
tion  and  design  Implementation  perfection  leave 
off.  Some  verification  and  evaluation  tech¬ 
niques  can  serve  early  In  the  design  process, 
even  before  hardware  and  software  Is  built. 
Others  serve  better  after  software  Is  built 
(with  or  without  target  hardware).  This  hand¬ 
book  supplements  the  MIL-ST0-882B  software 
hazard  analysis  task. 

l.l  CONTRACT  APPLICATION 

This  handbook,  of  and  In  Itself,  Is  not  con¬ 
strued  or  Implied  to  be  a  contractual  document. 
The  procuring  activity  must  extract  the  appli¬ 
cable  handbook  rules  and  guidelines  and  Include 
them  In  the  system  specification.  Specific 
tasks  and  data  Items  must  be  called  out  In  the 
Statement  of  Work  (SOW)  and  Identified  In  the 
Data  Item  Oescriptlons  (DID's). 


2.  SCOPE 

This  document  Is  Intended  for  use  primarily  by 
000  program  managers  and  technical  specialists 
In  the  areas  of  safety  and  software  engi¬ 
neering.  It  is  Intended  to  serve  as  a  companion 

document  to  MIL -STD -882  and  to  act  as  a  guide 
In  accomplishing  the  software  safety  task. 


2.1  ORGANIZATION  OF  THIS  HANDBOOK 

Following  this  Introduction,  this  document  has 
six  major  sections  and  three  appendices.  Sec¬ 
tion  3  contains  the  specific  DEFINITIONS  which 
will  be  used  throughout  the  document.  Section 
4,  INTRODUCTION,  begins  with  a  rationale  for 
software  safety  programs  and  the  philosophical 
background  and  outlook  necessary  for  a  success¬ 
ful  program.  Section  5,  DESIGN  GUIDELINES  FOR 
SOFTWARE  SYSTEM  SAFETY,  delves  Into  the  spe¬ 
cific  requirements  necessary  to  design  safety 
Into  software  systems  and  to  Insure  that  the 
software  design  Is  analyzable.  Section  6, 
SOFTWARE  SAFETY  ANALYSIS,  addresses  the  general 
philosophy  of  the  three  major  stages  of  soft¬ 
ware  safety  analysis.  Section  7,  SOFTWARE 
SAFETY  ANALYSIS  TECHNIQUES,  discusses  the 
various  techniques  used  for  this  analysis. 
Section  8,  SOFTWARE  SYSTEM  SAFETY  DESIGN  RULES 
AND  GUIDELINES,  contains  design  requirements 
and  guidelines  which  can  be  used  to  develop 
safe  software.  Appendices  A  through  C  contain 
examples  of  a  software  analysis  specification, 
a  request  for  proposal  (RFP)  and  a  statement  of 
work.  Please  note  that  the  appendices  are  exam¬ 
ples  only  and  are  not  designed  to  be  used  as 
written,  nor  do  they  Imply  any  preferred  analy¬ 
sis  methodology!  They  all  must  be  carefully 
tailored  to  reflect  the  analysis  method(s) 
desired  and  the  system  on  which  It  (they)  are 
to  be  applied! 

3.  DEFINITIONS 

For  definitions  not  specifically  listed  below, 
the  following  sources.  In  order  of  preference. 
Is  as  follows: 

a.  D0D-ST0-1679A  Military  Standard  Soft¬ 
ware  Development 

b.  IEEE  Standard  Glossary  of  Software 
Engineering  Terminology 

3.1  Built-in-test  (BIT).  A  hardware  and/or 
software- Implemented  check  Intended  to  detect 
prespecified  acceptable  conditions  (or  devia¬ 
tions  therefrom)  and  to  take  some  prespecified 
course  of  action  (I.e.,  warning,  alert,  shut¬ 
down)  upon  detection  of  an  anomaly. 


5  September  1985 


2 


3.2  Code  Walk* through.  A  manual  simulation  of 
predefined  test  cases  (I.e.,  test  Input  and 
expected  output)  led  by  the  programmer  and 
addressed  to  a  small  (e.g.,  3>6)  group  of 
qualified  personnel,  preferrably  personnel  not 
directly  Involved  with  the  program  being 
reviewed.  (See  also  Inspection) 

3.3  Design  Wa1k*through.  A  step-by-step 
detailed  examination  of  the  design  of  the 
software  by  a  small  group  of  qualified 
personnel. 

3.4  Level  Analysis.  Additional  to 
flow  of  control,  i.e.,  making  sure  each  data 
item  Is  correctly  referenced,  computed  or  used. 

3.5  Development,  Software.  The  engineering 
process  and  effort  that  results  In  software, 
encompassing  the  span  of  time  from  Initiation 
of  the  software  requirements/design  effort 
through  delivery  to  and  acceptance  by  the  con¬ 
tracting  agency. 

3.6  Erroneous  Bit.  A  single  bit  In  a  register 
or  memory  location  that  was  Intended  to  be  a 
■I*  which  was  Interpreted  as  a  “O*  (or  vice 
versa)  during  program  execution. 

3.7  Error,  Software.  An  occurrence,  or  lack 
thereof,  during  the  execution  of  a  program 
that  prevents  satisfaction  of  the  specified 
software  requirements,  falls  to  perform  as 
designed,  or  performs  a  function  not  required 
and/or  not  desired. 

3.8  Fault  Tree.  An  analytical  technique, 
whereby  an  undesired  system  state  Is  specified 
and  the  system  Is  then  analyzed  In  the  context 
of  Its  environment  and  operation  to  find  all 
credible  ways  In  which  the  undesired  event 
could  occur. 

3.9  Firmware.  Software  which  resides  In  non¬ 
volatile  computer  memory  that  Is  not  alterable 
by  the  computer  system  during  program  execu¬ 
tion.  For  the  purpose  of  system  safety,  firm¬ 
ware  is  to  treated  as  any  other  piece  of 
software. 

3.10  Flow  Chart /Diagram.  A  graphic  representa¬ 
tion  of  the  processing  order  or  execution  of 
Instructions  and  subroutines  In  which  symbols 
are  used  to  represent  operations,  data,  flow, 
equipment,  etc. 
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3.11  Graphic  Representations.  A  tool  used  to 
facilitate  the  translation  of  requirements  Into 
software  design  or  software  design  Into  source 
code.  They  are  Intended  to  be  comparable  to 
blue  prints  for  hardwars.  Examples  are  program 
design  languages  [PDL/Ada  (Ada  Is  the  trademark 
of  the  U.S.  Government,  Ada  Joint  Program 
Office)],  (Structured  English,  Pseudo-Code, 
Pidgin-Engllsh,  etc.),  functional  flow  dia¬ 
grams,  block  diagrams,  etc. 

3.12  Hardware.  Physical  parts  of  a  system, 
such  as  mechanical  and  electrical  componeri-c^ 
switches,  and  Input/output  devices. 

3.13  Inspection.  A  step-by-step  examination 
of  the  program,  lead  by  the  programmer  and 
addressed  to  a  small  group  of  qualified  person¬ 
nel,  preferably  personnel  not  directly  Involved 
with  the  program  being  reviewed.  During  the 
examination  each  step  Is  checked  against  a 
predetermined  list  of  criteria. 

3.14  Interface  Analysis.  An  analysis  of  mod¬ 
ule  Interfaces  and  associated  variables. 

3.15  Machine  Code.  Instructions  that  are 
Intended  to  be  Input  directly  Into  the 
Instruction  register  of  a  computer's  central 
processing  unit  (CPU). 

3.16  Microprocessor.  The  central  electronic 
device  which  actually  executes  the  software. 
(Usually  surrounded  by  peripheral  devices  such 
as  memory,  buffers,  decoders,  etc.,  which 
allow  Interaction  with  the  rest  of  the  system 
Involved.) 

3.17  Mnemonic  Operation  Codes.  Computer 
Instructions  written  In  a  meaningful  human 
notation,  I.e.,  ADD,  STD,  etc.,  but  which  must 
be  converted  on  a  one-to-one  basis  Into  machine 
language  for  computer  operation. 

3.18  Node.  A  point  where  several  paths  meet. 

3.19  Object  Code.  Compiler  or  assembler  output 
that  Is  Itself  executable  machine  code  or  tnat 
can  be  processed  to  produce  executable  machine 
code.  For  the  purpose  of  software  analysis, 
object  code  Is  normally  analyzed  by  looking  at 
Its  mnemonic  representation.  This  mnemonic 
code  can  be  produced  by  compilers  which  produce 
Intermediate  assembler  code  or  through  a  disas¬ 
sembly  process. 
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3.20  RAM.  Randon  access  nenory. 

3.21  Requirements  Walk-through.  A  step-by- 
step,  detailed  examination  of  the  requirements 
of  the  software. 

3.22  ROM.  Read  only  memory. 

3.23  Safety  Critical.  Those  software  opera¬ 
tions  that.  If  not  performed,  performed  out-of¬ 
sequence,  or  performed  Incorrectly  could  result 
In  Improper  control  functions  (or  lack  of  con¬ 
trol  functions  required  for  proper  system 
operation)  which  could  directly  or  indirectly 
cause  or  allow  a  hazardous  condition  to  exist. 

3.24  Soft  Tree.  A  term  coined  to  describe  a 
fault  tree  which  Is  constructed  on  a  system 
which  Includes  a  software  Interfacing  with 
hardware.  A  software  fault  tree. 

3.25  Software.  A  combination  of  associated 
computer  Instructions,  statements,  and  com¬ 
puter  program  data  definitions  required  to 
enable  the  computer  hardware  to  perform  compu¬ 
tational  or  control  functions.  Note:  This 
definition  Includes  firmware  within  Its  appli¬ 
cability.  This  definition  of  software  Is  Inde¬ 
pendent  of  the  type  of  physical  storage  media 
In  which  the  software  resides. 

3.26  Software  Element.  A  constituent  part  of 
the  system's  software.  The  following  would  be 
examples  of  software  or  program  elements: 
programs,  routines,  modules,  tables,  or 
variables. 

3.27  Software  Reliability.  The  probability 
that  the  software  will  execute  for  a  particu¬ 
lar  period  of  time  without  a  failure,  weighted 
by  the  cost  to  the  user  of  each  failure 
encountered. 

3.28  Software  Safety.  The  application  of 
system  safety  engineering  techniques  to  soft¬ 
ware  In  order  to  Insure  and  verify  that  the 
software  design  takes  positive  measures  to 
enhance  system  safety  and  that  errors  which 
could  reduce  system  safety  have  been  eliminated 
or  controlled  to  an  acceptable  level  of  risk. 

3.29  Software  Safety  Analysis.  A  hazard 
evaluation  technique  which  Identifies  software 
commands  (with  and  without  errors)  either  sin¬ 
gularly  or  In  combination  with  hardware 


responses  that  could  result  In  safety  critical 
hazards. 

3.30  Source  Code.  A  computer  program  written 
In  a  language  designed  for  ease  of  expression 
of  a  class  of  problems  or  procedures  by  human. 
A  generator,  assembler,  translator,  or  com¬ 
piler  Is  used  to  then  translate  the  source 
program  Into  object  code  for  use  by  the 
computer. 

3.31  System.  The  equipment,  facilities,  soft¬ 
ware,  operator,  maintalner,  and  technical  data 
associated  with  a  single  entity  (weapon 
system). 

3.32  System  Allocation  Documents.  Various 
specification  and  requirement  documents 
(requirements/performance  specifications)  which 
represent  the  flow  of  system-level  requirements 
Into  subsystems. 

3.33  System  Level  Analysis.  Analysis  con¬ 
cerned  with  flow  of  control,  and  data  Items  and 
variables  Influencing  It. 

4.  INTRODUCTION 

The  development  and  usage  of  microprocessors 
and  computers  has  grown  at  a  phenomenal  rate  In 
recent  years,  from  1955,  when  only  10  per  cent 
of  our  weapon  systems  required  computer  soft¬ 
ware,  to  today,  when  the  figure  Is  to  over  80 
per  cent.  This  Increased  reliance  on  computers 
has  put  the  aerospace  Industry  and  the  military 
In  the  position  of  controlling  hazardous  sys¬ 
tems  with  computers  and  associated  software. 
Examples  of  this  Include  the  Mlnuteman  and 
Peacekeeper  weapon  systems  and  the  F-16  fly- 
by-wire  system.  This  use  of  computers,  while 
Improving  system  performance,  has  also  compli¬ 
cated  the  Job  of  the  safety  engineer  as 
methods  to  ensure  the  safety  of  the  computer- 
controlled  aspects  of  the  systems  has  lagged 
behind  the  development  of  the  systems. 

Traditionally,  In  safety  analyses,  the  computer 
subsystem  and  the  software  It  contains  have 
been  considered  a  "black  box*  that  gives  a 
specific  output  based  on  a  given  Input  and  has 
not  been  considered  In  the  safety  analysis 
process.  However,  as  the  use  of  software- 

controlled  systems  has  grown,  so  has  the  Inci¬ 
dence  of  mishaps  directly  attributable  to 
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53ftware  Increased.  It  has  become  very  appar¬ 
ent  that  software  can  no  longer  be  Ignored  from 
a  safety  standpoint. 

4.1  THE  SOFTWARE  HAZARD 

It  Is  well  understood  that  software  In  and  of 
Itself  Is  not  Intrinsically  hazardous;  however, 
once  the  software  Is  associated  with  a  system. 
It  becomes  as  potentially  hazardous  as  the 
total  system.  For  a  hazard  to  occur,  there 
must  be  some  undesired/uncontrolled  release  of 
energy,  energy  normally  contained  by  some 
hardware  component(s) .  The  failure,  malfunc¬ 
tion,  or  error  In  control  of  that  hardware  must 
cause  or  allow  the  hazard  to  occur;  therefore, 
normally  only  software  which  exercise  direct 
command  and  control  over  the  condition  or 
state  of  the  hardware  components  or  can  monitor 
the  state  of  the  hardware  components  are  con¬ 
sidered  critical  from  a  safety  viewpoint. 
Software  which  controls  and  monitors  systems, 
such  as  missiles  or  aircraft,  are  considered 
to  be  hazardous.  However,  other  systems  that 
provide  Indirect  control  or  data  for  critical 
processes,  such  as  the  attack  warning  system 
at  NORAO  or  flight  navigation  systems,  must 
also  be  considered  as  hazardous,  as  erroneous 
data  can  lead  to  potentially  hazardous  erro¬ 
neous  decisions  by  the  human  operators  or  com¬ 
panion  systems. 

Software  hazards  fall  Into  four  broad  catego¬ 
ries:  (a)  Inadvertent/unauthorized  event,  an 

unexpected/unwanted  event  occurs;  (b)  out-of- 
'sequence  event,  a  known  and  planned  event 
occurs  but  not  when  desired;  (c)  failure  of 
event  to  occur,  a  planned  event  doss  not  occur 
(c.g.,  a  hazard  Is  allowed  to  propagate  because 
the  program  does  not  detect  the  occurrence  of 
the  hazard  or  falls  to  act);  (d)  magnitude  or 
direction  of  event  Is  wrong,  this  Is  normally 
Indicative  of  an  algorithm  error. 

Traditionally,  the  failure  of  the  computer  has 
been  viewed  only  from  a  standpoint  of  elect¬ 
ronic  component  failures  In  reliability  and 
safety  analyses.  The  electronics  can  be  ana¬ 
lyzed  and  mean  time  between  failures  (MTBF) 
assigned.  However,  an  KTBF  cannot  be  directly 
applied  to  software  as  software  does  not  fall. 
The  "software  failures"  are  actually  errors 
built  Into  the  program.  These  errors  fall  Into 
two  main  classes:  (a)  Incorrect  or  Incomplete 
specifications  and  requirements  which  leads  to 
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Incorrect  or  Incomplete  designs,  or  (b)  soft¬ 
ware  errors  made  during  programming  or  coding. 

A  third  failure  class  Is  hardware  related; 
software  errors  occur  due  to  a  hardware- Induced 
corruption  of  the  program.  Software  changes  due 
to  the  effects  of  radiation  bombardment  of  RAM 
fall  Into  this  category. 

The  fact  that  software  does  not  fall  does  not 
make  the  Issue  of  safety  analysis  easier.  In 
theory,  a  properly  designed  testing  program 
could  detect  all  errors.  In  practice,  however, 
this  becomes  virtually  Impossible  due  to  the 
many  possible  combinations  of  sequences  and  the 
timing  of  those  sequences  with  respect  to  one 
another.  Further,  modern  software  testing 
Includes  time  compression  techniques  which 
tend  to  make  error  windows  so  small  that  the 
window  may  not  be  hit  and  the  errors,  there¬ 
fore,  undetected.  Additionally,  as  tests  tend 
to  reflect  the  requirements  to  which  the  soft¬ 
ware  was  written,  errors  In  the  requirements 
are  seldom  detected  by  testing. 

In  the  past  short  history  of  software  devel¬ 
opment,  much  of  the  testing  or  debugging  has 
been  accomplished  by  trial  and  error.  When  an 
error  was  detected,  the  software  code  was  ana¬ 
lyzed  and  a  change  was  made.  This  process  took 
time,  and  latent  software  errors  often  lay 
unnoticed  during  development  only  to  appear 
after  the  product  had  been  fielded.  Modern 
weapon  systems  cannot  afford  to  be  programmed 
by  such  methods,  as  latent  errors  can  lead  to 
system  destruction. 

4.2  MANAGEMENT  CONSIDERATIONS 

Software  safety,  which  Is  a  subset  of  system 
safety.  Is  a  relatively  new  field  and  Is  going 
to  require  a  conscientious  effort  by  all  those 
Involved  In  any  system  acquisition  process  or 
development  effort  to  Insure  It  Is  adequately 
addressed  during  system  development.  Hardware 
and  software  engineering  efforts  must  be 
accomplished  as  a  team  effort.  Engineers  must 
attend  their  counterpart's  specification  and 
design  reviews  so  that  they  are  fully  aware  of 
hardware/ software  and  other  Interfaces  and  how 
each  of  their  efforts  are  Interdependent  and 
how  they  jointly  affect  safety.  System  safety 
personnel  must  have  (or  have  access  to)  the 
appropriate  hardware  and  software  expertise 
and  must  also  always  maintain  a  ‘total  systems* 
viewpoint. 
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A  (ptclal  effort  eust  be  node  to  Insure  that 
appropriate  requirements  are  transmitted  to  the 
contractors.  A  good  up-front  effort  to  define  a 
system  safety  theme  and  Insure  that  proper 
safety  requirements  are  contained  In  requests 
for  proposals  (RFPs)  and  specifications  will 
save  time,  money,  and  possibly  lives  over  the 
system  lifetime.  Just  as  a  good  system  safety 
program  needs  to  begin  when  a  project  Is 
started,  so  must  the  efforts  to  Insure  software 
safety.  Specific  up-front  requirements  Imposed 
upon  the  software  development  effort  will  help 
Insure  that  safety  Is  designed  Into  the  soft¬ 
ware  and  that  the  required  safety  analyses  can 
be  easily  and  Inexpensively  accomplished. 

5.  DESI6N  GUIDELINES  FOR  SOFTWARE  SYSTEM 
SAFETY 

S.l  SYSTEM  C6NS10ERAT10MS 

The  foremost  factor  In  Insuring  system  safety 
Is  to  Insure  that  the  entire  system  be  looked 
at  at  a  system,  not  separate  hardware  and  soft¬ 
ware  elements.  At  the  very  Inception  of  a  sys¬ 
tem  development  effort,  a  system  safety  theme 
needs  to  be  Identified  which  will  specify  how 
fault  tolerant  the  system  must  be  and  how  the 
system  It  to  handle  faults;  I.e.,  must  the 
system  work  at  least  at  tome  level  of  operation 
or,  given  a  certain  clast  of  fault  must  the 
system  shut  Itself  down  or  Initiate  some  spe¬ 
cific  procedure?  This  theme  will  then  serve  at 
a  general  guide  as  to  hardware  and  software 
design  requirements  and  Is  one  of  the  first 
steps  In  specifying  system  safety  requirements. 

The  next  step  It  to  Insure  that  appropriate 
requirements  are  Included  In  the  RFPs,  state¬ 
ments  of  work,  contracts,  and  the  system  and 
subsystem  specifications.  In  addition  to  the 
system  specific  requirements,  the  following 
documents  of  the  Issue  In  effect  as  of  the  date 
of  the  contract  should  be  Included  In  contract 
requirements: 


TABLE  5.1.  APPLICABLE  DOCUMEMTATIOM 


DOCUMENT  NUMBER 

DOCUMENT  NAME 

NIL-STD-S62 

System  Safety  Program 
Requirements 

NIL-STD-483 

Configuration  Management 
Practices  for  Systems, 
Equipment,  Munitions,  and 
Computer  Programs 

NIL-$T0-490 

Specification  Practices 

DOD-STO-1679 

Software  Development 
Standard 

000 -STD-480 

Configuration  Control  - 
Engineering  Changes, 
Deviations  and  Waivers 

AFR  122-10 
(If  applicable) 

Nuclear  Safety  Design  and 
Evaluation  Criteria 

5.2  HARDWARE  CONSIDERATIONS  FOR  SOFTWARE 
SAFETY 


If  software  has  anything  which  even  resembles  a 
failure  mode.  It  Is  In  the  area  of  hardware- 
induced  failures.  Just  as  when  a  hardware 
component  falls  and  causes  other  component  or 
system  failures,  the  same  effect  also  applies 
to  software.  A  hardware  failure  can  cause  a 
bit  error  In  a  computer  word  which  Induces  a 
software  failure  because  the  software  Instruc¬ 
tion  no  longer  has  Its  original  meaning.  The 
failure  mechanism  Is  entirely  within  the  hard¬ 
ware,  but  the  software  Is  erroneous  because  it 
has  a  new  and  unintended  meaning.  These  fail¬ 
ures  may  be  permanent  or  a  temporary  glitch  due 
to  effects  such  as  alpha  particle  radiation. 
Hardware  design  and  software  should  attempt  to 
take  these  problems  Into  account  and  provide  a 
method  of  flagging  them  and  reducing  their 
effect  (e.g.,  parity  check  on  memory  data  and 
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software  comands  prior  to  acceptance).  It 
■  nould  be  noted  that  a  BIT  will  probably  not 
catch  a  soft  error  (glitch).  Also,  hardware 
sensor  failures  can  provide  erroneous  Inputs. 
When  operated  on  by  the  software,  erroneous 
judgements  are  made,  resulting  In  Improper 
commands  being  Issued.  Again,  the  failure 
mechanism  Is  entirely  In  the  hardware,  but  the 
software  outputs  are  erroneous  and  defeat 
proper  system  operation.  Therefore,  credible 
hardware  failure  modes  must  drive  design 
requirements,  both  of  the  hardware  and  of  the 
software. 


5.3  REQUIREMENTS  FOR  THE  VARIOUS  PHASES  OF 
SYSTEM  DEVELOPMENT 

5.3.1  Specification  Phase 

The  development  of  system  and  subsystem  speci¬ 
fications  Is  one  of  the  most  crucial  activities 
during  a  system  development  effort.  This  Is 
especially  true  for  system  safety  and  specif¬ 
ically  for  software  safety.  Without  appropri¬ 
ate  and  adequate  safety  requirements  In  the 
development  specifications,  software  may  nei¬ 
ther  provide  the  desired  degree  of  safety  nor 
even  be  analyzable.  In  general,  the  software 
must  be  designed  to  an  acceptable  level  of 
risk,  given  that  failures,  errors,  and  adverse 
environmental  conditions  will  occur.  This 
requires  that  a  general  software  safety  phi¬ 
losophy  be  decided  early  In  the  program  and  be 
so  stated  In  the  requirements  documents.  Also, 
to  help  Insure  that  developed  programs  are 
analyzable,  OOO-STD-1679,  000  Software  Develop¬ 
ment  Standard,  or  similar  structured  program¬ 
ing  requirements  should  be  levied  upon  the 
contract. 

The  safety  effort  must  begin  by  defining  both 
general  and  specific  safety  requirements  for 
the  top-level  system  specifications.  These 
requirements  must  then  be  flowed  down  to  the 
lower-tiered  specifications.  As  this  flowdown 
process  takes  place,  there  must  be  Increased 
attention  placed  on  the  specific  safety 
functional  requirements  of  the  Individual  sub¬ 
systems.  For  Instance,  hazards  Identified  In 
the  preliminary  hazard  analysis  may  drive 
specific  requirements  for  Inclusion  In  a  com¬ 
puter  program  configuration  Item  (or  even  how  a 
particular  problem  must  be  solved  In  rare 
cases). 


Safety  critical  functions  and  elements  must  be 
Identified  early  and  appropriate  safety  design 
criteria  provided  for  them  In  the  specifica¬ 
tions.  These  criteria  should  Include  possible 
methods  for  risk  avoidance  (e.g.,  safety  kernel 
techniques  or  the  use  of  safety  assertions)  and 
possibly  an  ordered  precedence  of  various 
methodologies  (e.g.,  program  design  Inhibits, 
Interlocks,  hardware  configuration,  or  opera¬ 
tional  plans  and  procedures).  Additionally, 
requirements  for  entrancy/reentrancy  con¬ 
straints,  output  monitoring,  and  hardware 
status  checking  must  be  specified  and  the 
requirement  for  testing/analysis  called  out. 

The  two  greatest  difficulties  encountered  at 
this  stage  of  development  are  that  many  cf  the 
actual  requirements  are  not  known  and  that 
system/subsystem  Interfaces  are  not  accurately 
described  or  understood.  Compounding  these 
difficulties  are  system  designs  which  push  the 
state-of-the-art  on  one  or  more  technological 
fronts.  To  help  overcome  these  difficulties, 
one  of  the  best  tools  available  Is  'history!* 
Similar  programs  or  activities  should  be 
actively  reviewed  to  glean  lessons  learned 
data.  From  a  generic  basis,  the  following  have 
already  proven  to  be  safety  concerns: 

a.  Routines  which  disable  Interrupts 
should  be  considered  safety  critical. 

b.  Conditional  statements  must  be  reviewed 
to  Insure  that  conditions  are  correctly  stated 
and  that  the  conditions  can  and  will  be  appro¬ 
priately  met  (e.g.,  conditions  that  call  for  an 
exact  match  of  floating  point  numbers  can 
easily  result  In  an  Infinite  loop). 

c.  What  conditions  can  result  In  a  divide 
by  zero  or  what  are  the  effects  of  other  analo¬ 
gous  singularities  In  the  program?  Hot  only 
can  a  divisor  of  zero  cause  this  problem  but 
also  'very  small*  numbers  may  be  truncated  to  a 
zero  by  the  software. 

d.  Priority  of  fault  detection  and  safing/ 
correction  logic  vs  normal  processing  *1n  line* 
logic. 

e.  Can  the  system  and  routines  handle  the 
amount  and  frequency  (load)  of  data?  Addition¬ 
ally,  is  the  precision  and  scaling  of  data 
appropriate  and  what  conditions  could  cause  a 
hazardous  condition? 
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f.  With  systems  utilizing  technologically 
advanced  Ideas,  IR&D  and  proof*of-des1gn  labo¬ 
ratory  demonstration  hardware  figures  heavily 
In  the  proposed  developmental  design.  Conse¬ 
quently,  basic  building  block  safety  provisions 
must  be  pressed  Into  such  laboratory/ 
exploratory  designs,  even  though  "system* 
safety  at  that  point  has  little  meaning. 

5.3.2  Design  Phase 

Once  the  specifications  have  been  written,  the 
next  task  Is  to  translate  those  requirements 
Into  an  actual  design.  It  Is  Important  to  again 
stress  that  safety  1$  the  Joint  responsibility 
of  all  those  concerned  on  a  development  effort. 
Engineering  must  translate  specification  safety 
requirements  Into  the  actual  design,  and  with 
the  quality  and  safety  offices,  insure  the 
accuracy  of  algorithms.  Interfaces,  and  other 
requirements  that  could  affect  system  safety. 
The  selected  safety  philosophy,  as  well  as 
structured  programing  techniques,  should  be 
strictly  adhered  to.  Software  critical  Items 
(see  PHA)  shall  follow  modular  design  tech¬ 
niques  and  shall  be  separated  from  and  not  be 
Intertwined  within  non-critical  Items. 

The  software  hazard  analysis  effort  (described 
In  section  6)  should  begin  early  during  soft¬ 
ware  development  by  analyzing  the  various  pro¬ 
gram  design  documents,  such  as  flowcharts, 
program  structure  documents,  etc.,  for  compli¬ 
ance  with  safety  requirements  and  to  Identify 
potentially  hazardous  conditions.  It  Is  Impor¬ 
tant  to  stress  that  the  software  cannot  be 
looked  at  In  a  vacuum.  It  Is  Just  one  part  of 
the  overall  system,  and  a  mishap  can  occur  when 
It  directly  or  Indirectly  Influences  a  hazard¬ 
ous  system  action  or  activity.  Closely  related 
to  the  safety  analysis  effort  Is  the  need  for  a 
strong  configuration  control  program  which  will 
Identify  changes  to  critical  software  elements 
which  have  been  previously  examined. 

5.3.3  Coding  Phase 

As  during  the  previous  design  phase,  system 
safety  Is  the  responsibility  of  all  concerned 
with  the  design  process.  The  coding  effort  must 
be  reviewed  by  software-knowledgeable  quality 
assurance  personnel  through  code  walk-throughs, 
and  other  methods  to  Insure  accuracy,  compli¬ 
ance  with  software  engineering  and  safety 
design  requirements,  and  to  Identify  errors. 


Safety  personnel  will  continue  the  software 
safety  analysis  by  examining  the  source/target 
machine  executable  code  of  safety  critical 
elements  and  Insuring  the  Independence  of  these 
modules  from  noncritical  elements.  These  pe'- 
sonnel  will  also  ascertain  that  the  program 
performs  Its  Intended  functions  correctly,  and 
that  It  does  not  perform  any  unintended  func¬ 
tions  (e.g.,  no  extraneous  code).  Independent 
testing  of  segments  of  code  must  be  completed 
prior  to  the  segment  being  Incorporated  Into 
the  main  code  package. 

5.3.4  Testing  Phase 

From  a  safety  viewpoint,  complete  and  thorough 
testing  of  a  system  may  neither  practical  nor 
desirable  due  to  the  costs  and/or  resourcrs 
Involved.  However,  testing  roust  show  that  all 
hazards  that  have  been  Identified  have  been 
either  eliminated  or  controlled  to  an  accept¬ 
able  level  of  risk.  Safety  testing  must  verify 
that  not  only  will  the  system  function  normally 
within  specified  environments  but  also  test 
for  reaction  to  failures  and  boundary  condi¬ 
tions  and  abnormal/out-of-bound  environments 
(e.g.,  ’negative*  *what-1f'  testing).  Safety 
Inhibits,  traps.  Interlocks,  assertions,  etc., 
must  be  verified  by  test  or  simulation.  It  Is 
vital  that  all  code  within  the  program  be  exe¬ 
cuted  at  least  once  and  each  decision  brought 
to  each  of  Its  possible  outcomes  at  least  once, 
although  no  necessarily  In  every  combination. 

Depending  upon  the  type  and  Importance  of  the 
system.  Independent  safety  and  verification  ana 
validation  should  be  considered. 

5.3.5  Deployment/Operatlonal/Haintenance  Phase 

Software  safety  does  not  terminate  with  the 
deployment  of  a  system.  All  complex  software 
programs  have  "bugs",  many  of  which  are  not 
found  until  after  the  system  becomes  opera¬ 
tional.  The  way  In  which  those  bugs  are  fixed 
determines  whether  or  not  the  software  Is  or 
remains  "safe*.  The  single  most  dangerous  act 
In  software  maintenance  Is  to  allow  a  machine 
language  patch  to  a  single  module  without  car. 
fully  analyzing  the  Impact  of  that  change  to 
the  rest  of  the  software.  Sometimes  a  seem¬ 
ingly  Innocuous  change  can  cause  system  wide 
devastation.  All  changes,  not  Just  those  to 
safety  critical  code,  should  be  reviewed  for 
Impact  to  the  safety  of  the  overall  system. 
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Cringes  to  baselined  software  docuMntatlon  and 
odes  are  normally  controlled,  processed,  and 
Implemented  In  accordance  with  a  software  con¬ 
figuration  management  system.  Software  safety 
needs  to  ensure  that  special  emphasis  Is  given 
to  the  safety  aspects  of  changes  that  are  han¬ 
dled  In  such  a  manner.  In  order  to  carry  out 
this  effort,  all  changes  to  previously  analyzed 
specifications,  requirements,  designs,  codes, 
and  test  plans,  procedures,  cases,  or  criteria 
are  subjected  to  a  software  hazard  analysis. 

The  beginning  point  of  this  change  hazard 
analysis  will  depend  upon  the  highest  level 
within  the  documentation  that  1$  affected  by 
the  changed  being  proposed.  For  example,  when 
the  change  affects  the  Software  Top  Level 
Design  Document,  the  analysis  of  the  change 
begins  with  the  top-level  design  analysis  soft¬ 
ware  safety  tasks  defined  earlier.  Appropriate 
subtasks  under  that  analysis  and  all  subsequent 
analysis  subtasks  should  be  performed  until 
either: 

a.  All  appropriate  subtasks  have  been 
completed,  or 

b.  It  Is  determined  that  the  change  nei¬ 
ther  creates  a  new  hazard  nor  Impacts  on  one 
which  has  already  been  resolved. 


There  are  also  software  safety  considerations 
regarding  the  Installation  of  firmware  changes 
during  these  phases.  When  the  software  for  a 
system  Is  contained  In  firmware  (ROMs),  and 
changes  for  the  software  are  fielded  as  new 
ROMs,  consideration  must  be  given  to  ensuring 
that  the  ROMs  are  Inserted  properly,  and  in  the 
correct  order.  Even  when  the  firmware  Is  dis¬ 
tributed  as  full  occupied  circuit  cards,  con¬ 
sideration  must  be  given  as  to  whether  multiple 
cards  can  be  swapped,  or  whether  a  card  can  be 
Inserted  backwards.  If  the  software  Is  dis¬ 
tributed  as  magnetic  media  (tapes,  disks, 
floppies,  etc.),  extra  consideration  must  be 
given  to  the  proper  Installation. 

Besides  Just  proper  physical  Installation, 
there  also  must  be  a  method  of  verifying  that 
the  changes  are  being  made  on  a  system  at  the 
Intended  modification  level.  If  other  modifi¬ 
cations  are/have  been  Issued,  how  does  the 
field  unit  ensure  that  the  software  changes 
being  Inserted  are  made  to  a  system  that  has 


the  right  modifications,  or  that  has  not  been 
already  modified?  Software  changes  may  not  be 
readily  apparent  above  the  code  level.  This  Is 
especially  Important  If  the  change  Is  Issued  as 
a  partial  set  of  ROMs,  and  does  not  Involve  a 
complete  swap  out.  If  several  modifications 
are/have  been  made  to  the  software  In  this 
fashion,  sooner  or  later  one  modification  wifi 
be  made  before  the  previously  Issued  one  (or 
one  w11)  make  It  through  the  paperwork  before 
the  other).  Since  all  software  depends  on  a1) 
of  the  other  software  In  a  system,  this  can 
have  disastrous  effects. 

Some  good  rules  for  software  field  maintenance 
Include  the  following; 

a.  Whenever  possible.  Issue  firmware 
changes  as  fully  populated  and  tested  circuit 
cards. 

b.  If  fully  populated  cards  cannot  be 
Issued,  then  Issue  complete  ROM  sets,  numbered 
and/or  color  coded.  Analyze  the  software  for 
the  effects  of  Improper  Insertion  (one  or  more 
swaps),  and  provide  a  method  for  field 
verification  of  proper  Insertion  (BIT  or 
checksum). 

c.  If  a  complete  set  of  ROMs  cannot  be 
Issued,  then  ensure  that  no  safety  critical 
code  modules  cross  the  address  space  between 
old  and  new  ROMs.  That  Is,  the  safety  critical 
code  should  be  entirely  contained  In  the  new 
firmware  or  In  the  old  firmware.  There  should 
bn  no  cases  In  which  part  of  a  safety  critical 
module  Is  In  the  old  firmware  and  part  Is  in 
the  new  firmware.  Field  verification  of  the 
proper  Installation  and  Integrity  of  the 
complete  system  software  Is  essential.  Make 
sure  that  the  difference  between  subsequent 
modifications  can  be  detected  by  BIT  or 
checksum. 

d.  If  the  changes  are  issued  as  magnetic 
media.  Include  an  automatic  patching  utility 
which  checks  to  ensure  that  It  Is  patching  the 
proper  revision  level  of  the  software,  and 
which  then  changes  the  revision  level  of  the 
Installed  software. 

e.  If,  as  a  last  resort,  or  If  the  changes 
ore  very  minor,  the  software  Is  Issued  as  writ¬ 
ten  Instructions,  they  should  be  Inserted  using 
a  checksum  verification  utility. 
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6.  SOFTWARE  SAFETY  AHALtSlS 

6.1  PREw ININARY  AND  FOLLOW-ON  SOFTWARE  HAZARD 
AHALt*'  J 

Software  hazard  analysis  Is  accomplished  so 
that  the  total  system  will  operate  at  an 
acceptable  level  of  risk.  To  be  effective, 
analysis  must  be  started  early  enough  to 
actively  Influence  the  design  of  both  the  soft¬ 
ware  and  the  total  system.  The  analysis  effort 
Ts  started  when  the  system  allocation  process 
has  delineated  the  responsibilities  between  the 
hardware  and  software.  The  software  hazard 
analysis  must  be  structured  to  permit  continual 
revision  and  updating  as  system  and  software 
design  matures. 

6.1.1  Preliminary  Software  Hazard  Analysis 

The  preliminary  software  hazard  analysis  Is  a 
direct  offshoot  of  the  system  preliminary  haz¬ 
ard  analysis  (PHA).  As  It  Is  normally  cost 
prohibitive  to  analyze  all  system  software  to 
the  same  depth,  the  system  PHA,  when  Integrated 
with  the  requirements  levied  upon  the  software, 
will  Identify  those  programs,  routines,  or 
modules  that  are  critical  to  system  safety  and 
must  be  examined  Indepth.  These  software  ele¬ 
ments  shall  be  Identified  as  safety  critical. 
However,  all  software  must  be  analyzed  at  least 
to  the  extent  necessary  to  determine  any  Impact 
or  Influence  upon  the  safety  critical  code. 
All  programs,  routines,  modules,  tables,  or 
variables  which  control  or  directly/indirectly 
Influence  the  safety  critical  code  shall  also 
be  classified  as  safety  critical.  Additionally, 
some  or  alt  of  the  software  tools  (e.g.,  com¬ 
pilers,  support  software,  etc.)  may  also  have 
to  be  designated  as  'critical*.  All  safety 
critical  software  elements  will  be  analyzed  to 
the  source/object  code  level  by  the  follow-on 
software  hazard  analysis. 

The  preliminary  software  hazard  analysis  Is 
accomplished  by  analyzing  the  following 
documents: 

a.  System  and  subsystem  preliminary  hazard 
analyses 

b.  System  and  subsystem  specifications. 

c.  System  allocation  and  Interface 
documents. 


d.  Functional  flow  diagrams  and  related 
data. 

e.  Flow  charts  or  their  functional 
equivalent. 

f.  Storage  allocation  and  program  struc¬ 
ture  documents. 

g.  Background  Information  related  to 
safety  requirements  associated  with  the  cor  tom 
plated  testing,  manufacturing,  storage,  repair, 
and  use. 

h.  System  energy,  toxic  and  hazcrdous 
event  sources  which  are  controlled  or  Influ¬ 
enced  by  software. 


6.1.2  Follow-on  Software  Hazard  Analysis 

The  follow-on  software  hazard  analysis  Is  a 
continuation  of  the  preliminary  software  hazard 
analysis  and  begins  when  coding  of  the  software 
begins,  normally  following  the  critical  design 
review  (COR).  Those  software  elements  that 
have  been  previously  Identified  as  being  safety 
critical  shall  be  analyzed  at  the  source/ 
machine  executable  code  level.  The  level  of 
effort  required  depends  on  the  perceived  risks. 
In  certain  instances.  If  the  source  code  Is 
written  In  a  high  order  language  and  there  Is  a 
high  level  of  system  risk  Involved,  the  run 
time  object  code  should  be  analyzed  to  Insure 
that  the  compilation  or  Interpretation  process 
has  not  Introduced  any  hazards  or  negated  any 
safety  design  efforts. 

Additional  activities  that  occur  during  the 
follow-on  analysis  Include  a  review  of  all 
hardware/software,  software/software,  and 
software/operator  Interfaces  and  of  critical 
data  (e.g.  flies,  etc.).  Analysis  Is  accom¬ 
plished  on  all  algorithms,  and  calculations  for 
correctness  and  Input/output/timing  sensitiv¬ 
ity.  While  some  of  these  activities  may  fill 
under  the  purview  of  QA  and/or  reliability, 
those  elements  affecting  safety  critical  ele¬ 
ments  must  be  reviewed  by  system  s-<'e‘v. 
Also,  system  safety  must  continue  its  active 
monitoring  of  the  design  and  coding  effort, 
with  special  attention  being  placed  on  design/ 
program  changes.  When  a  program  Is  submitted 
for  analysis,  it  should  also  be  placed  unde*- 
In-house  configuration  concrol  so  that  the 
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an^.lysls  report  will  reflect  a  known  program 
version,  and  If  changes  are  made,  safety  will 
know  of  the  changes. 


7.  SOFTWARE  HAZARD  ANALYSIS  METHODOLOGIES 

Although  not  an  exhaustive  list,  the  following 
techniques  can  be  used  to  help  provide  a  thor¬ 
ough  software  hazard  analysis.  Additionally,  a 
thorough  software  hazard  analysis  of  a  system 
may  require  application  of  more  than  one  of  the 
following  techniques  or  others  not  yet  identi¬ 
fied  In  this  document. 


7.1  SOFTWARE  FAULT  TREE  (SOFT  TREE) 

Before  the  topic  of  the  software  fault  tree  can 
be  discussed,  a  brief  description  of  fault 
trees  In  general  is  needed.  The  following  three 
paragraphs  are  taken  from  the  US  Nuclear 
Regulatory  Commission  NURE6-0492,  ‘Fault  Tree 
Handbook,"  January  1981: 

"The  fault  tree  analysis  can  be  simply 
described  as  an  analytical  technique, 
whereby  an  undesired  state  of  the  system 
Is  specified  (usually  a  state  that  Is 
critical  from  a  safety  standpoint),  and 
the  system  Is  then  analyzed  In  the  con¬ 
text  of  Its  environment  and  operation  to 
find  all  credible  ways  In  which  the 
undesired  event  can  occur.  The  fault  tree 
Itself  Is  a  graphic  model  of  the  various 
parallel  and  sequential  combinations  of 
faults  (or  system  states)  that  will 
result  In  the  occurrence  of  the  prede¬ 
fined  undesired  event.  The  faults  can  be 
events  that  are  associated  with  component 
hardware  failures,  human  errors,  or  any 
other  pertinent  events  which  can  lead  to 
the  undesired  event.  A  fault  tree  thus 
depicts  the  logical  Interrelationships  of 
basic  events  that  lead  to  the  undesired 
event--wh1ch  Is  the  top  event  of  the 
fault  tree. 

it  Is  Important  to  understand  that  a 
fault  tree  Is  not  a  model  of  all  possible 
system  failures  or  all  possible  causes 
for  system  failure.  A  fault  tree  1$ 
tailored  to  Its  top  event  which  corre¬ 
sponds  to  some  particular  system  failure 
mode,  md  the  fault  tree  thus  Includes 


only  those  faults  that  contribute  to 
this  top  event.  Moreover,  these  faults 
are  not  exhaustive — they  cover  only  the 
most  credible  faults  as  assessed  by  the 
analyst. 

It  Is  also  Important  to  point  out  that  a 
fault  tree  Is  not  In  Itself  a  quantita¬ 
tive  model.  It  Is  a  qualitative  model 
that  can  be  evaluated  quantitatively  and 
often  Is.  This  qualitative  aspect,  of 
course.  Is  true  of  virtually  all  varie¬ 
ties  of  system  models.  The  fact  that  a 
fault  tree  Is  a  particularly  convenient 
model  to  quantify  does  not  change  the 
qualitative  nature  of  the  model 

Itself." 


7.1.1  The  Soft  Tree 

The  term  soft  tree  has  been  coined  to  describe 
a  fault  tree  which  includes  software  Inter¬ 
facing  with  hardware.  The  software  fault  tree 
proceeds  In  a  manner  similar  to  hardware  fault 
tree  analysis  and  uses  a  subset  of  the  symbols 
currently  In  use  In  the  hardware  counterparts. 
Thus,  hardware  and  software  trees  can  be  linked 
together  at  their  Interfaces  to  allow  the 
entire  system  to  be  analyzed.  This  Is  extremely 
Important  since  software  safety  procedures 
cannot  be  developed  In  a  vacuum  but  must  be 
considered  as  part  of  the  overall  system 
safety.  For  example,  a  particular  software 
error  may  cause  a  mishap  only  If  there  Is  a 
simultaneous  human  and/or  hardware  failure. 
Alternatively,  the  environmental  failure  may 
cause  the  software  error  to  manifest  Itself. 
The  soft  tree  also  can  help  Identify  credible 
fault  modes  within  the  computer  system,  such 
as  flag  or  register  failures,  which  will  cause 
the  software  to  act  In  an  undesired  manner. 

The  first  step  In  the  software  fault  tree  Is 
conducting  a  PKA  analysis  to  Identify  and  cate¬ 
gorize  the  hazards  posed  by  the  system. 
Classifications  range  from  "catastrophic*  to 
"negligible."  Once  the  hazards  have  been 
determined,  fault  tree  analysis  proceeds.  It 
should  be  noted  that  In  a  complex  system.  It  Is 
likely  that  not  all  hazards  can  be  predeter¬ 
mined.  This  fact  does  not  decrease  the  neces¬ 
sity  of  Identifying  as  many  hazards  as  possible 
but  does  Imply  that  additional  procedures  may 
be  necessary  to  Insure  system  safety. 
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The  goal  of  software  fault  tree  analysis  Is  to 
show  that  the  logic  contained  In  the  software 
design  will  not  produce  system  safety  failures. 
A  further  goal  Is  to  determine  environmental 
conditions  which  could  lead  to  these  software 
Induced  failures.  The  basic  procedure  Is  to 
assume  that  the  software  will  lead  to  a  catas¬ 
trophe  and  then  to  work  backward  to  determine 
the  set  of  possible  causes  for  the  condition  to 
occur. 

The  root  of  the  fault  tree  Is  the  event  to  be 
analyzed,  I.e.,  the  “loss  event,'  Necessary 
preconditions  are  described  at  the  next  level 
of  the  tree  with  either  an  AND  or  an  OR  rela¬ 
tionship.  Each  subnode  Is  expanded  In  a  similar 
fashion  until  all  leaves  describe  events  of 
calculable  probability  or  are  unable  to  be 
analyzed  for  some  reason.  Further  Information 
on  the  general  construction  of  fault  trees  can 
be  found  In  NliREG-0492  and  specific  Information 
on  soft  trees  can  be  found  In  "SOFT  TREE,  Fault 
Tree  Techniques  as  Applied  to  Software'  by  the 
Directorate  of  Systems  Safety.  Armament  Divi¬ 
sion,  Air  Force  Systems  Command,  Eglin  Air 
Force  Base. 

Soft  tree/ fault  tree  analysis  can  be  used  at 
various  levels  and  stages  of  software/  system 
development  and  the  level  of  node  development 
can  also  be  tailored  depending  upon  how  the 
tree  is  to  be  used  and  the  corresponding  stage 
of  software/ system  design.  Thus,  the  analysis 
can  proceed  and  be  viewed  at  various  levels  of 
abstraction  from  trees  derived  from  program 
flows  or  a  program  design  language  (POL)  to 
final  trees  whose  nodes  are  at  the  code  level. 
It  Is,  therefore,  desireable  to  build  the  Ini¬ 
tial  trees  early  during  the  software  life  cycle 
so  that  safety  can  be  designed  Into  the  soft¬ 
ware  during  Its  development.  (Software  fault 
trees  can  also  utilize  the  network  tree  data 
base  generated  during  a  software  sneak 
analysis.) 

When  working  at  the  code  level,  the  starting 
place  for  the  analysis  Is  the  code  responsible 
for  the  output.  The  analysis  then  proceeds 
backward  deducing  both  how  the  program  got  to 
this  part  of  the  code  and  determining  the  cur¬ 
rent  values  of  the  variables.  It  Is  at  this 
level  that  processor  and  computer  faults  can 
also  be  Identified.  For  example,  a  soft  tree 
event  could  read  'carry  flag  set.*  The  Input 
to  this  event,  as  a  minimum,  should  Include  an 


OR  gate  with  at  least  two  Inputs:  (1)  carry 
occurred  due  to  some  calculation,  and  (2) 
carry  flag  bit  failed  high.  Again,  the  final 
goal  of  the  analysis  Is  total  system  safety, 
and  this  will  require  that  the  analysis  be 
done  by  persons  knowledgeable  of  the  computer 
equipment  and  languages  being  used.  As  with  any 
fault  tree,  the  safety  engineer  must  know  the 
system  he  has  to  analyze  and  make  every  attempt 
to  model  the  system  accurately. 

As  a  final  note,  to  facilitate  this  analysis, 
as  well  as  system  safety,  software  should  be 
developed  such  that  the  majority  of  the  safety 
critical  functions,  decisions,  and  algorithms 
are  within  a  single  (or  few)  software  devel¬ 
opment  modules.  This,  as  well  as  a  structure! 
approach  that  protects  against  Inadvertent 
Jumps,  etc.,  will  significantly  reduce  the 
scope  of  work  that  Is  needed  on  a  given  tree  as 
the  tree  will  only  need  to  extend  down  to  the 
code  level  for  only  extremely  critical  parts  of 
the  software. 

7.1.2  Uses  of  Fault  Trees 

7. 1.2.1  Cutset  Analysis 

Boolean  (I.e.,  logic  or  circuit)  algebra  may  be 
applied  to  the  fault  tree  to  find  the  minimum 
cutsets,  which  are  all  combinations  of  basic 
events  (component- level  and  often  quantifiable 
events)  which  will  cause  the  top  event.  The 
algebra  removes  the  Intermediate  logical  Inter¬ 
relationship  levels  of  the  tree,  converting  the 
tree  to  an  equivalent  form  which  Is  In  terms  of 
basic  events  only. 

The  cutsets  show  which  single-point  failures, 
double-point  failures,  and  higher-order  fail¬ 
ures  are  possible  and  which  lead  to  occurrence 
of  the  top  event.  The  number  of  events  In  each 
cutset  shows  the  amount  of  Inhibits,  In  differ¬ 
ent  combinations,  on  the  occurrence  of  the  top 
event. 

Cutset  analysis  computer  programs  are  avail¬ 
able,  such  as  FTAP,  SETS,  PREP,  ALLCUTS,  and 
ELRAFT. 

7. 1.3. 2  Quantitative  Analysis 

If  component  failure  rates  and  hazard  outaclon 

times  are  available  for  each  basic  event,  a 
probability  of  the  top  event  may  be  calculated. 
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Conv3rseljr,  given  a  desired  probability  of  the 
tot  event,  allowable  time  for  operation  of  the 
system  may  be  calculated. 

In  addition,  basic  events  or  cutsets  may  be 
ranked  quantitatively  as  to  their  relative 
Importance  to  the  top  event. 

This  quantitative  analysis  of  the  fault  trees 
Is  traditionally  a  hardware  analysis  technique 
where  a  'component*  Is  easily  defined.  Experi¬ 
mental  attempts  are  being  made  to  define  soft¬ 
ware  components  and  to  determine  failure  rates 
for  these. 

Computer  programs  are  available  for  quantita¬ 
tive  analysis.  Including  IMPORTANCE,  BACSIM, 
KITT,  SAMPLE,  MOCARS,  and  FRANTIC. 

7. 1.2. 3  Common  Cause  Analysis 

Common  cause  analysis  deals  with  dependencies 
between  events  In  a  cutset.  For  example,  a 
cutset  may  contain  three  events,  'transistor  X 
shorts,*  'transistor  T  shorts,*  and  'transistor 
Z  shorts.*  If  all  three  events  occur,  the  top 
event  will  occur  (the  system  will  fall).  If 
all  three  events  can  be  triggered  by  an  exter¬ 
nal  common  cause,  such  as  heat,  and  If  heat  Is 
present,  the  system  will  fall. 

In  the  case  of  software,  common  cause  analysis 
can  be  applied  to  cutsets  to  determine  environ¬ 
mental  effects  on  top  events.  For  example.  If 
the  contents  of  two  registers  are  thought  to  be 
affected  by  a  certain  environment,  and  both  are 
In  the  save  cutset,  the  cutset  Is  a  more  Impor¬ 
tant  possible  system  failure  mode  when  that 
environment  Is  present. 

Computer  programs,  such  as  COMCAN,  BACKFIRE, 
and  SETS,  are  available  to  a1d  In  the  sorting 
of  events  In  cutsets  to  locate  common 
susceptibilities. 

7.2  SOFTWARE  SNEAK  CIRCUIT  ANALYSIS 

Five  specific  software  analysis  techniques  are 
described  In  the  material  that  follows.  The 
techniques  are  basically  static  analyses.  Some 
of  the  Information  on  analysis  techniques  other 
than  software  sneak  analysis  has  been  obtained 
from  'Checkout  Techniques,  Software  Reliabil¬ 
ity  Guidebook,*  Prentice-Hall,  1979;  Robert  L. 
Glass. 


Software  sneak  analysis:  Data  used  for  software 
sneak  analysis  should  reflect  the  program  as  It 
Is  actually  written.  This  Includes  system 
requirements,  system  description,  coding  speci¬ 
fications,  detailed  and  complete  source  code,  a 
compilation  listing,  and  operating  system  docu¬ 
mentation.  All  records  are  written  against 
these  documents. 

Software  Sneak  Analysis  1$  used  to  discover 
program  logic  which  causes  undesired  program 
outputs  or  Inhibits  a  desired  output.  The  tech¬ 
nique  Involves  the  reduction  of  the  program 
source  code  to  topological  network  tree  repre¬ 
sentations  of  the  program  logic. 

Direct  analysis  of  program  listings  Is  diffi¬ 
cult  because  the  system  Is  modular  for  ease  of 
programing.  Also,  the  code  Is  listed  as  a  file 
or  record,  without  regard  to  functional  flow. 
The  first  task  of  the  software  sneak  analyst 
Is  to  convert  the  program  source  code  Into  a 
form  usable  for  analysis.  In  most  cases,  this 
step  requires  computer  conversion.  In  either 
case,  the  program  source  code  Is  converted  with 
reference  to  an  input  language  description 
file  Into  topological  network  trees  such  that 
program  control  Is  considered  to  flow  down  the 
page. 

Once  the  trees  have  been  drawn,  the  analyst 
Identifies  the  basic  topological  patterns  that 
appear  In  the  trees.  Six  basic  patterns  exist: 
the  single  line,  the  return  dome,  the 
Iteratlon/loop  circuit,  the  parallel  line,  the 
entry  dome,  and  the  trap  circuit,  as  shown 
below: 


Single  Line  Return  Dome  Iteration  Loop 


V  V  't'  w 

0  1  0  \  /  / 

\  J  \ _ /  / 

I  ^ 

'  i  '1 

Parallel  Line  Entry  Dome  Trap 
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In  a  sjrstee  level  analysis,  code  Is  aodelled  In 
terms  of  Impedances,  powers,  grounds,  switches, 
nodes,  and  relay  colls  and  switches.  Trees  are 
constructed  hlerarchally,  so  that  the  analysis 
proceeds  from  the  top  down.  In  a  system  level 
analysis,  the  following  topographs  are  Identi¬ 
fied: 


Software  sneaks  are  classified  Into  four  basic 
types: 

a.  Sneak  output  -  the  occurrence  of  an 
undesired  output. 

b.  Sneak  Inhibit  -  the  undesired  Inhibi¬ 
tion  of  an  output. 


Unit  Binary  Multiplexer  Loop 


0  1  0 
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Decoder 
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Although  at  first  glance  a  given  software  tree 
may  appear  to  be  more  complex  than  these  basic 
patterns,  closer  Inspection  will  reveal  that 
the  code  Is  actually  composed  of  these  basic 
structures  In  combination.  As  each  node  In  the 
tree  Is  examined,  the  analyst  must  identify 
which  pattern  or  patterns  Include  that  mode. 
The  analyst  then  applies  the  topograph  specific 
clues  that  have  been  found  to  typify  the  sneaks 
Involved  with  that  particular  structure.  These 
clues  are  In  the  form  of  questions  that  the 
analyst  must  answer  about  the  use  and  Inter¬ 
relationships  of  the  Instructions  that  are 
elements  of  the  structure.  These  questions  are 
designed  to  aid  in  the  Identification  of  the 
sneak  conditions  In  the  Instruction  set  which 
could  produce  undesired  program  outputs. 


c.  Sneak  timing  -  the  occurrence  of  an 
undesired  output  by  virtue  of  Its  timing  or 
misswtched  Input  timing. 

d.  Sneak  message  -  the  program  message 
does  not  adequately  reflect  the  condition. 

When  potential  sneak  Is  Identified,  the  analyst 
must  verify  that  It  Is  valid.  The  code  Is 
checked  against  the  latest  listing.  Compiler 
Information  may  be  reviewed  concerning  the 
language  In  question.  If  the  sneak  Is  veri¬ 
fied,  a  software  sneak  report  (SSR)  Is  written 
which  Includes  an  explanation,  system-level 
Impact,  and  a  recommendation  for  elimination  of 
the  sneak. 

During  the  course  of  analysis,  questionable 
programing  practice  or  Instruction  Implementa¬ 
tions  may  be  encountered  and  are  reported  In  a 
software  design  concern  report  (SDCR). 

If  two  or  more  documents  or  the  program  listing 
and  a  supporting  document  do  not  agree,  the 
program  listing  Is  assumed  to  be  correct.  If 
the  analyst  then  determines  that  the  condition 
Is  not  a  software  sneak  or  questionable  prac¬ 
tice,  a  software  documentation  error  report 
(SDER)  Is  Issued  for  the  discrepancy. 

The  following  paragraphs  describe  various  meth¬ 
ods  of  analysis  used  In  the  software  analysis: 

a.  Desk  checking.  Desk  checking  Is  one  of 
the  earliest  forms  of  software  verification. 
It  Involves: 

(1)  Reviewing  a  program  listing  for 
faults  and  compliance  to  requirements, 

(2)  Performing  arithmetic  calculations 
to  verify  output  value  correctness,  and 

(3)  Manually  simulating  program  execu¬ 
tion  In  order  to  understand  and  verify  program 
logic  and  data  flow. 
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Since  desk  checking  Is  such  an  Ill-defined 
cjncept.  It  Is  difficult  to  provide  a  cost 
estimate  for  Its  use.  It  Is  undoubtedly  true, 
however,  that  moderate  amounts  of  desk  checking 
save  more  money  than  they  generate  in  cost. 

Desk  checking  efforts  concentrate  on  areas  of 
special  problems,  especially  suspected  errors 
or  code  Inefficiencies,  and  Involve  techniques 
appropriate  to  that  problem. 

b.  Code  Walk-through.  Code  walk-through 
1$  a  process  by  which  a  team  of  programing 
personnel  (I.e.,  technologists)  do  an  Indepth 
review  of  a  program,  or  portion  of  a  program, 
by  Inspection.  In  general,  the  participants 
are  verbally  lead  sequentially  through  the 
logic  flow  of  the  program  as  represented  In 
the  listing.  (Note:  the  leader  should  not  be 
the  responsible  programmer)  All  logic  branches 
should  be  taken  at  least  once.  The  function  of 
each  statement  will  be  discussed  as  It  Is 
encountered.  Program  requirements  and  design 
specifications  will  be  present  for  correlation 
of  function  to  Its  driving  factors. 

The  walk-through  should  not  occur  until  after 
coding  of  the  program  to  be  reviewed  Is  com¬ 
pleted,  well  annotated,  and  syntactically 
correct. 

c.  Structural  analysis.  A  structural  ana¬ 
lyzer  Is  an  automated  tool  that  seeks  and 
records  errors  In  the  structural  makeup  of  a 
computer  program  undergoing  analysis.  Struc¬ 
tural  analysis  Is  a  relatively  new  concept, 
beginning  In  the  early  1970s.  Structural  analy¬ 
zers  are  almost  always  language  and  Installa¬ 
tion  or  project  specific.  Most  structural 
analyzers  built  to  date  accommodate  only  FOR¬ 
TRAN  or  COBOL.  For  example,  OAVE,  built  at  the 
University  of  Colorado,  processes  COC-6000 
FORTRAN  programs  looking  for  uninitialized 
verlables  via  a  very  elaborate  algorithm. 

The  major  factor  In  the  cost  of  a  structural 
analysis  Is  the  acquisition  of  a  structural 
analyzer.  Costs  can  range  from  trivial.  If  the 
program  Is  already  In  the  public  domain,  to 
upwards  of  $100,000  for  Implementation  of  an 
elaborate  analytical  tool. 

d.  Proof  of  correctness.  Proof  of  correct¬ 
ness  Is  the  process  of  using  mathematical 
theorem-proving  concepts  on  a  computer  program 


or  Its  design  to  show  that  It  Is  consistent 
with  Its  specification.  This  Is  done  by 
breaking  the  program  Into  logical  segments, 
defining  Input  and  output  assertions  for  each 
segment,  and  demonstrating  that,  when  the  pro¬ 
gram  functions.  If  all  Input  assertions  are 
true,  then  so  too  are  all  output  assertions.  It 
must  also  be  shown  that  the  program  success¬ 
fully  terminates. 

Many  researchers  are  currently  working  In  the 
proof-of-correctness  area.  Small  algorithms 
and  programs  have  been  proven  In  this  environ¬ 
ment;  however.  It  has  yet  to  be  demonstrated  on 
programs  of  any  significant  size. 

Even  for  small  simple  programs,  the  symbolic 
manipulations  Involved  In  the  proof-of- 
correctness  technique  can  be  overly  complex. 
Introducing  errors  Into  the  computation  of  the 
statements  to  be  proven  as  well  as  the  proof  of 
those  statements.  Thus,  the  technique  would  be 
most  successful  on  highly  mathematical  and 
relatively  straightforward  program  segments. 

Lack  of  practical  experience  with  proof  of 
correctness  makes  It  difficult  to  quantify 
costs.  Usage  costs  are  significant,  possibly 
adding  100  to  500  percent  to  the  cost  of  the 
portion  of  the  software  being  proven.  However, 
by  lowering  the  projected  mishap  number,  the 
life  cycle  cost  of  the  system  could  be  substan¬ 
tially  reduced. 

Specification  requirement  for  sneak  analysis: 
The  sneak  analysis  specifications  are  currently 
listed  1n  KIL-ST0-785B,  Reliability  Program 
for  Systems  and  Equipment  Development  and 
Production. 

7.3  NUCLEAR  SAFETY  CROSS-CHECK  ANALYSIS 
(NSCCA) 

NSCCA  Is  a  rigorous  methodology  developed 
exclusively  to  satisfy  the  requirements  of  Air 
Force  Rsgulatlon  122-9  and  Is  accomplished  by 
an  agency  or  contractor  who  Is  Independent 
from  the  program  developer.  (Some  names  of 
activities  and  plans  vary  depending  upon  the 
bronch  of  service  but  the  Intent  remains  the 
same)  The  methodology,  to  a  great  degree,  Is  an 
adversarial  approach  to  software  analysis  In 
that  Its  basic  objective  Is  to  show,  with  a 
high  degree  of  confidence,  that  the  software 
will  not  contribute  to  an  undesirable  event. 
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The  NSCCA  process  has  two  components:  technical 
and  procedural.  The  technical  component  evalu¬ 
ates  the  software  by  analysis  and  test  to 
assure  that  It  satisfies  the  system's  nuclear 
safety  objectives.  The  procedural  component 
Implements  security  and  control  measures  to 
protect  against  sabotage,  collusion,  compro¬ 
mise,  or  alteration  of  critical  software  com¬ 
ponents,  tools,  and  NSCCA  results.  (Note: 
While  this  method  was  originally  designed  to 
meet  the  needs  of  nuclear  systems,  the  method 
can  be  tailored  and  applied  where  ever 
desired.) 


7.3.1  Technical  Component  of  NSCCA 

The  technical  component  begins  with  a  criti¬ 
cality  analysis  which  maps  the  nuclear  safety 
objectives  against  the  discrete  functions  of 
the  software  system.  Qualitative  Judgments  are 
made  to  assess  the  degree  to  which  each  func¬ 
tion  affects  the  nuclear  safety  objectives,  and 
suggestions  for  the  best  methods  to  measure  the 
software  functions  are  made.  The  program  man¬ 
ager  uses  the  criticality  assessment  to  decide 
where  best  to  allocate  resources  to  meet  the 
requirements,  then  the  NSCCA  program  plan  Is 
drawn.  The  program  plan  establishes  the  tools 
and  facilities  requirements,  analyses  require¬ 
ments,  test  requirements,  test  planning,  and 
test  procedures.  This  family  of  documents 
establishes  In  advance  the  evaluation  crite¬ 
ria,  purpose  and  objectives,  and  expected 
results  for  specific  NSCCA  analyses  and  tests. 
Establishing  these  details  beforehand  promotes 
the  Independence  of  NSCCA  and  avoids  Vubber- 
stamplng.” 


7. 3. 1.1  Derivation  of  Nuclear  Safety  Objec¬ 
tives  (NSO) 

The  first  step  In  criticality  analysis  1$  deri¬ 
vation  of  the  NSO.  NSOs  are  derived  from  000 
Directive  5030/15  and  AFR  122-10.  000  5030/15 
directs  that,  for  nuclear  weapons  systems, 
positive  measures  be  taken  to: 

a.  Prevent  nuclear  weapons  Involved  In 
accidents  or  Incidents  from  producing  a 
nuclear  yield. 


b.  Prevent  deliberate  prearming,  arming, 
launching,  firing,  or  releasing  of  nuclear 
weapons,  except  upon  execution  of  emergency  war 
orders  or  when  directed  by  competent  authority. 

c.  Prevent  Inadvertent  prearming,  arming, 
launching,  firing,  or  releasing  of  nuclear 
weapons. 

d.  Insure  adequate  security  of  nuclear 
weapons. 

These  four  000  safety  standards  define  the 
undesirable  events,  detonation,  pre^.r.^ln'', 
arming,  launching,  firing,  releasing,  and  loss 
which  are  to  be  protected  against.  The  fourth 
standard  Is  also  satisfied  In  the  procedural 
component  of  NSCCA. 

AFR  122-10,  Nuclear  Safety  Design  and  Evalua¬ 
tion  Criteria,  breaks  down  the  four  000  stan¬ 
dards  Into  specific  requirements  which  are  the 
minimum  positive  measures  necessary  to  demon¬ 
strate  that  nuclear  weapon  system  software  is 
predictably  safe.  The  combination  of  000  safety 
standards  and  the  design  criteria  form  the 
menu  of  NSO. 

7. 3.1. 2  Functional  Breakdown  of  the  System 
Software 

Step  two  of  the  criticality  analysis  Is  to 
break  down  the  total  software  system  Into  the 
lowest  order  of  discrete  functions  or  modules. 
It  Is  Intuitively  obvious  that  the  more  modular 
a  system  Is  the  more  easily  analyzable  It  be¬ 
comes.  Once  the  system  Is  broken  down  to  the 
lowest  order  of  function,  each  function  Is 
analyzed  to  determine  the  degree  to  which  It 
operates  on  or  controls  a  nuclear  critical 
event  (I.e.,  prearming,  arming,  etc.).  Modules 
which  have  no  Influence  on  the  nuclear  critical 
events  are  not  Included  for  further  analysis. 
A  matrix  Is  then  prepared  plotting  software 
modules  against  the  NSO  and  an  Influence  rat¬ 
ing  given  (high  -  h,  medium  -  m,  low  -  1  ). 
Alto  prospective  evaluation  techniques  are 
shown.  Mith  the  criticality  analysis  In  hand, 
program  management  can  determine  the  best 
course  of  action  to  pursue  the  NSCCA. 
Figure  7.3.1  shows  an  example  of  a  criticality 
analysis. 
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7.3.1 

7. 3. 1.3  Conduct  of  the  NSCCA 


7. 3. 1.3.1  NSCCA  Program  Plan 

The  program  plan  Identifies  detailed  NSCCA 
activities  and  schedules  compatible  with  the 
software  development  contractor's  schedule  of 
reviews  and  delivery  dates.  The  plan  also  con¬ 
tains  man-loading  estimates  for  each  activity. 

7. 3. 1.3. 2  NSCCA  Tools/Facllltles  Plan 

The  tools/facllltles  plan  Identifies  software 
tools  to  be  used  In  each  analysis  task.  All 
required  tools  are  described.  For  new  or  modi¬ 
fied  tools.  It  provides  schedules  for  develop¬ 
ment  and  Identifies  quality  assurance  methods 
to  be  applied  to  the  tool  development  process. 
The  plan  also  describes  requirements  for  test 
facilities  and  schedules  for  testing. 

7. 3. 1.3. 3  NSCCA  Test  Requirements 

The  test  requirements  document,  which  Is 
derived  from  the  system  and  software  require¬ 
ments  specifications.  Identifies  all  perfor¬ 
mance  and  safety  requirements  to  be  analyzed 
and  tested.  It  also  Identifies  requirements 
Imposed  on  the  test  tools  in  order  to  properly 
evaluate  system  end-item  requirements.  Test 
requirements  are  Initially  derived  from  speci¬ 
fication  documents  by  the  criticality  analy¬ 
sis.  In  addition,  hidden  safety  requirements 
Implied  by  the  coupling  of  requirements  or 
system  constraints  are  Identified  and  recorded 
for  analysis  and  test. 


7.3.1. 3.4  NSCCA  Test  Plan 

The  test  plan  Identifies  the  scope  of  testing 
to  be  applied  to  each  nuclear  critical  perfor¬ 
mance  requirement  Identified  In  test  require¬ 
ments.  The  scope  of  each  test  Is  defined  by 
establishing  an  analysis  or  test  scenario  for 
each  requirement. 


7. 3. 1.3. 5  NSCCA  Test  Procedures 

The  test  procedures  Identify  how  the  scope  of 
testing  described  In  the  test  plan  will  be 
achieved.  For  each  test  scenario,  detailed 
procedures  are  developed  specifying  the  Input, 
tooKs),  and  expected  output  from  the  test. 
The  test  procedures  begin  after  completion  of 
the  test  plan  and  after  review  of  the  detailed 
program  design  and  coding.  As  errors  or  defi¬ 
ciencies  are  detected  In  the  program  source 
code,  specifications.  Interface  documents,  data 
base  description  documents,  or  other  design 
related  documents,  they  are  recorded  on  dis¬ 
crepancy  reports. 

7. 3. 1.3.6  NSCCA  Final  Report 

The  final  report  summarizes  the  NSCCA  activi¬ 
ties  and  results  and  presents  conclusions  and 
reconunendatlons  regarding  program  performance 
and  safety.  The  final  report  concludes  whether 
the  system  sufficiently  compiles  with  Its  per¬ 
formance  and  safety  requirements  to  warrant 
certification  for  operational  use. 

7.3.2.  Procedural  Component  of  NSCCA 

Nuclear  weapons  system  software  subjected  to 
NSCCA  ascends  to  the  Air  Force  Critical  Compo¬ 
nents  List  and,  as  such,  comes  under  the  provi¬ 
sions  of  AFR  122-4,  Nuclear  Safety:  The  Two-Nan 
Concept.  The  objective  of  this  program  Is  to 
protect  the  software  from  any  environment  which 
could  subject  It  to  possible  compromise  or 
alteration.  To  establish  equal  confidence  In 
the  NSCCA,  the  same  level  of  protection  must 
apply  to  the  analysis  environment.  A  high  level 
of  confidence  Is  achieved  by  Instituting  strong 
personnel,  document,  and  facility  security 
measures,  coupled  with  stringent  product  con¬ 
trol  procedures. 
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7. 3. 2.1  NSCCA  Personnel  Security 

Special  precautions  are  taken  to  Insure  the 
trustworthiness  of  participants  and  the  Integ¬ 
rity  of  results.  Special  background  Investi¬ 
gations  are  conducted  for  all  project 
personnel  who  participate  In  NSCCA  activities. 
Each  participant  In  foraal  NSCCA  analyses  or 
test  will  be  cleared  for  SECRET  and  CNUOI 
before  cooaienclng  work.  In  addition,  project 
engineers  will  be  cleared  for  TOP  SECRET, 
CONSEC,  and  cryptographic  Information. 

7. 3. 2. 2  NSCCA  Document  Security 

Each  of  the  completed  documents  used  or  pro¬ 
duced  during  NSCCA  Is  kept  under  configuration 
control  to  Insure  only  current  data  are  dis¬ 
tributed.  Distribution  lists  are  maintained 
for  each  document  so  that  all  Initial  recipi¬ 
ents  receive  any  updates  or  changes.  Master 
copies  of  documents  are  retained  In  the  project 
files  with  classified  documents  stored  In 
approved  6SA  containers. 

7. 3. 2. 3  NSCCA  Test  Facility  Security 

Rigorous  security  controls  are  exercised  during 
Interim  and  formal  NSCCA  testing  to  maintain 
the  Integrity  of  machine-readable  program  code 
and  test  data  and  to  prevent  unauthorized 
access  to  classified  Information.  All  classi¬ 
fied  code  and  data  are  stored  on  clearly  marked 
physical  media  (disks  and  tapes)  which  Is 
secured  In  6SA-approved  containers  when  not  In 
use.  During  classified  operations,  access  to 
the  facility  Is  restricted  to  appropriately 
cleared  personnel  with  an  established  need  to 
know.  Terminals  external  to  the  facility  are 
physically  detached  from  the  computers  to  pre¬ 
vent  unauthorized  access  to  classified  Infor¬ 
mation.  During  formal  NSCCA  operations, 
two-person  control  restrictions  apply  to  NSCCA 
testing  performed  In  the  facility. 

7. 3.2. 4  NSCCA  Product  Control 

Strict  configuration  management  Is  exercised 
for  software  Items  used  during  Interim  and 
formal  NSCCA.  This  Includes  successive  versions 
of  the  system  software,  qualified  test  tools, 
prescribed  Input  data  sets,  and  program 
patches.  Each  qualified  test  tool  Is  kept  under 
configuration  control  so  that  analysis  end 
test  results  will  be  valid  and  repeatable. 


During  formal  NSCCA  activities,  two-person 
control  Is  Implemented  over  all  nuclear  criti¬ 
cal  program  materials  to  prevent  their  Inadver¬ 
tent  or  unauthorized  alteration.  Critical 
documentation  Items,  such  as  performance  speci¬ 
fications,  design  specifications.  Interface 
control  documents,  test  plans,  test  procedures, 
as  well  as  controlled  software  (Includes  pro¬ 
gram  source  and  load  tapes,  program  patches, 
and  qualified  software  tools),  are  stored  in 
two-person  controlled  containers  when  not  In 
use.  An  audit  scheaM  Is  established  to  pre¬ 
serve  two-person  control  as  materials  are  used. 
Uhenever  two-person  controlled  Items  are 
removed  from  storage,  they  are  kept  under  sur¬ 
veillance  by  two  authorized  persons  at  all 
times.  All  tape  or  disk  manipulations  are 
performed  In  such  a  manner  that  both  people  can 
Insure  that  the  tape  or  disk  Is  not  altered. 
Comparisons  and  spot  checks  are  performed  peri¬ 
odically  to  Insure  that  working  copies  and 
controlled  copies  are  Identical. 

7.4  SAFETY  ANALYSIS  USIN6  PETRI  NETS 

7.4.1  A  Petri  net  (Invented  by  Carl  Petri  In 
1961)  Is  a  mathmaatlcal  model  of  a  system.  One 
of  the  advantages  of  Petri  nets  over  other 
models  Is  that  the  user  describes  the  system 
using  a  graphical  notation  and  thus  need  not  be 
concerned  with  the  mathematical  underpinnings 
of  Petri  nets.  Soaw  other  potenital  advantages 
of  using  Petri  net  models  Include: 

They  can  be  used  early  In  the  development 
cycle  so  that  changes  can  be  made  while  sill 
relatively  Inexpensive. 

A  system  approach  Is  possible  with  Petri  nets 
since  hardware,  software,  and  human  behavior 
can  be  modeled  using  the  same  language. 

Petri  nets  can  be  used  at  various  levels  of 
detraction. 

Petri  nets  provide  a  modeling  language  which 
can  be  used  for  both  formal  analysis  and 
simulation. 

Adding  time  and  probabilities  to  basic  Petri 
nets  allows  Incorporation  of  timing  and  probab¬ 
ilistic  Information  Into  the  analysis. 

The  model  may  be  used  to  analyze  the  system 
for  other  features  besides  safety. 
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Fetri  nets  have  been  used  primarily  to  analyze 
performance  and  "correctness*  (especially  with 
regard  to  synchronization  problems  in  concur* 
rent  systems),  however.  It  has  been  proposed 
that  they  can  be  used  to  analyze  system  designs 
for  safety  and  fault  tolerance.  Unlike  the 
fault  tree,  the  safety  analysis  can  be  accom¬ 
plished  by  a  computer  without  human  guidance 
because  the  design  Is  first  represented  as  a 
mathematical  system.  Furthermore,  If  a  com¬ 
plete  analysis  becomes  Impractically  large,  the 
model  can  be  executed  on  the  computer  In  a 
simulation  mode  and  Important  Information  about 
the  design  derived.  For  example,  faults  can  be 
Injected  and  the  result  examined.  Finally, 
timing  analysis  may  be  more  easily  accomplished 
with  a  Petri  net  model  than  with  fault  trees. 
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Figure  7.4.1 

In  a  Petri  net,  the  system  Is  modelled  In  terms 
of  conditions  and  events.  If  certain  condi¬ 
tions  hold,  then  an  event  or  "state  transition* 
will  take  place.  After  the  transition,  other 
(or  the  same)  conditions  will  hold.  A  condi¬ 
tion  (called  a  "place*  In  Petri  net  terminol¬ 
ogy)  Is  represented  by  a  circle  *0*  and  an 
event  or  transition  by  a  bar.  An  arrow  from  a 
condition  (or  place)  to  a  transition  Indicates 
that  the  condition  Is  an  Input  (or  pre¬ 
condition)  to  the  transition.  Similarly,  a 
post-condition  Is  Indicated  by  an  arrow  from 
the  transition  to  the  condition.  Figure  7.4.1 
shows  a  simple  example.  It  says  that  If  condi¬ 
tions  A  and  B  hold,  then  the  transition  can 
"fire."  After  It  fires,  then  conditions  B  and 
C  will  hold. 

The  Petri  net  model  can  be  "executed*  to  see 
how  the  design  will  actually  work.  "Tokens* 
represented  by  a  dot  *••  are  used  to  Indicate 
that  a  condition  Is  currently  true.  Thus  If  a 


condition  bolds.  It  will  contain  a  token.  In 
the  example  In  Figure  7.4.2,  transition  t^ 
cannot  fire  because  P^  does  not  have  a  token. 
But  all  the  pre-conditions  for  X,2  are  currently 
true  (I.e.  ^3)'  ^2  fire.  Figure 

7.4,3  shows  the  next  state  of  the  Petri  net. 
When  t2  fires,  the  tokens  are  removed  from  the 
pre-conditions  and  a  token  Is  deposited  In  each 
of  the  post-conditions.  In  the  example,  the 
only  post-condition  Is  P^.  Note  that  It  Is 
possible  for  the  same  condition  to  be  a  pre¬ 
condition  and  a  post-condition  for  a  transi¬ 
tion.  If  a  transition  has  no  pre-conditions, 
then  It  can  fire  at  will. 
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Figure  7.4.2 
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During  the  execution  of  the  Petri  net,  the 
"state*  of  the  system  at  any  time  consists  of 
the  set  of  conditions  which  contain  tokens. 
Starting  from  some  Initial  state,  the  Petri  net 
model  can  be  executed  showing  all  the  legal 
states  (sets  of  conditions)  that  the  system  can 
"reach."  This  Information  can  be  depicted 
graphically  In  a  "reachability  graph,"  I.e.  a 
graph  that  shows  the  possible  state  sequences 
from  a  given  Initial  state.  If  the  design  Is 
non-determ1n1$t1c  (I.e.  the  order  of  the  tran¬ 
sitions  or  events  Is  not  constrained  by  the 
design),  then  the  graph  will  have  branches  for 
the  different  possible  ordering  of  events. 
Figures  7.4.4  and  7.4.5  show  a  Petri  net  and 
the  corresponding  reachability  graph  for  a 
simple  model  of  a  railroad  crossing  where  the 
left  part  of  the  model  Is  controlling  the 
crossing  guard  gate  (which  Is  on  the 
The  reachability  graph  shows  that  the  design  Is 
flawed  (from  a  safety  standpoint)  since  It  1$ 
possible  for  the  train  to  be  and  the  crossing 
guard  gate  to  be  up  at  the  same  time.  Note  that 
It  also  shows  the  sequence  of  events  which  can 
lead  to  this  hazard  so  that  appropriate  meas¬ 
ures  can  be  taken  to  avoid  It. 
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.  .though  creating  the  entire  reachability  graph 
will  show  whether  the  system  as  designed  can 
reach  any  hazardous  states.  In  practice  the 
graph  Is  often  too  large  to  generate  com¬ 
pletely.  However,  It  Is  possible  to  use  the 
same  type  of  backward  analysis  used  In  fault 
trees.  Algorithms  have  been  developed  at  the 
University  of  California  Irvine  to  do  this 
backward  analysis.  Hazards  which  have  been 
determined  by  the  analysis  to  be  plausible  can 
be  eliminated  by  appropriately  altering  the 
design  to  ensure  that  paths  (sequences  of 
events)  which  will  lead  to  the  hazard  are  not 
taken.  For  example,  an  Interlock  to  ensure 
that  one  transition  or  event  always  proceeds 
another  Is  shown  In  Figure  7.4.6.  Figure  7.4.7 
shows  the  Petri  net  equivalent  of  a  lockout 
(I.e.  a  design  feature  that  ensures  that  two 
conditions.  In  this  case  conditions  P3  and  P^, 
do  not  hold  at  the  same  time). 
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Figure  7.4.6.  Figure  7.4.7. 

Interlock  Locking  Place 


Faults  and  failures  can  be  Incorporated  Into 
the  model  to  determine  their  effect  on  the 
system.  Backward  procedures  can  determine 
which  failures  and  faults  are  potentially  the 
most  costly  and  therefore  which  parts  of  the 
system  need  to  be  augmented  with  fault- 

tolerance  and  fall-safe  mechanisms.  Early  In 
the  design  of  the  system.  It  Is  possible  to 
treat  the  software  parts  of  the  design  at  a 


very  high  level  of  abstraction,  I.e.  only  fail¬ 
ures  at  the  interfaces  at  the  interfaces  of  the 
software  and  non-software  components  may  be 
considered.  By  working  backward  to  this  soft¬ 
ware  Interface,  It  Is  possible  to  determine  the 
software  safety  requirements  and  to  determine 
which  functions  are  most  critical.  Timing  has 
been  added  to  Petri  net  models  by  putting  mini¬ 
mum  and  maximum  time  limits  or  transitions  or 
by  putting  times  on  conditions.  Either  way.  It 
Is  possible  to  determine  worst  case  timing 
requirements  so  that,  for  example,  watchdog 
timers  can  be  Incorporated  Into  the  design  If 
necessary.  Finally,  when  probabilities  are 
Included  In  the  model,  minimal  cut  sets  and 
other  probabilistic  Information  Is  obtainable. 

Although  Petri  nets  have  been  used  since  the 
1960* s,  the  application  of  the  technique  for 
safety  Is  still  experimental  (as  of  1985)  and 
has  had  little  real-world  validation.  However, 
It  appears  to  be  a  promising  tool  worth  further 
consideration. 


8.  SOFTWARE  SYSTEM  SAFETY  DESIGN  RULES  AND 
6UIDELIHES 

8.1  This  section  Is  designed  to  act  as  a  guide 
In  providing  safety  requirements  for  system  and 
software  specifications.  It  Is  not  a  defini¬ 
tive  list  nor  can  It  be  applied  blindly.  The 
list  should  be  carefully  reviewed  and  tailored 
to  reflect  the  specific  applications  of  the 
system($)  under  development. 

8.2  The  Intent  of  the  the  following  rules  and 
quidellnes  Is  to  carry  out  the  cardinal  safety 
rule  and  Its  corollary  that  no  single  event  or 
action  shall  be  allowed  to  Initiate  a  poten¬ 
tially  hazardous  event  and  that  the  system, 
upon  detection  of  an  unsafe  condition  or  com¬ 
mand,  shall  Inhibit  the  potentially  hazardous 
event  sequence  and  originate  procedures  to 
bring  the  system  to  a  predetermined  'safe* 
state. 

8.2.1  Documentation  of  Requirements,  Designs, 
and  Intents 

8.2. 1.1  All  safing  requirements  shall  be 
detailed  in  the  software  design  specification. 

8.2. 1.2  The  system  shall  make  use  of  self 
test,  BIT,  and  fault  tolerant  concepts. 
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8. 2. 1.3  Interrupt  priorities  end  responses 
shall  be  specifically  docunented  and  analyzed 
for  safety  Impact. 

8. 2. 1.4  Techniques  for  deadlock  prevention/ 
detection/resolution  shall  be  provided. 

8. 2. 1.5  The  Intent  of  the  design  must  be 
clearly  stated  and  how  It  Is  to  be  accomplished 
In  the  target  code.  This  Includes,  but  Is  not 
necessarily  limited  to,  absolute/relative  time 
sequence,  bit  patterns,  multiple  data  checks, 
and  a  priori  tasks  performed. 

8. 2. 1.6  Critical  software  functions  must  not 
be  corrected  by  patching  In  a  language  other/ 
lower  than  the  source  code  designated  for  that 
software.  All  patches  must  be  clearly 
documented  for  meaning  and  logged  with  configu¬ 
ration  control  to  maintain  accurate  change 
trail  records  for  customer  acceptance  and 
delivery. 

8. 2. 1.7  Any  and  all  assumptions  concerning 
unknown  or  unstated  requirements  and/or  Inter¬ 
faces  at  any  level  of  hardware  or  software  must 
be  clearly  stated  for  the  target  code.  This 
Includes  *TBD*  requirements/ Interfaces  as  well 
as  missing  links/unspecifled  Items. 

8.2. 1.8  Any  and  all  deviations  and  waivers  to 
the  requirements  and/or  Interfaces  at  any  level 
of  hardware  or  software  must  be  clearly  stated 
for  the  target  code  Including  Implications  or 
explanations  to  limitations. 

8. 2. 1.9  The  operating  system  (OS)  software, 
as  much  of  It  that  Is  used  In  the  total  soft¬ 
ware,  must  be  clearly  described.  Including 
shareable  re-entrant  library-type  of  routines 
and  primitives.  The  portion  of  this  OS  soft¬ 
ware  used  by  the  critical  software  must  be 
clearly  Identified  as  to  the  purpose  for  which 
It  Is  used. 

8.2.2  Critical  Software/CPU/System  Design 
Rules 

8. 2. 2.1  Any  single  CPU  controlling  a  process 
which  could  result  In  major  system  loss,  dam¬ 
age,  or  loss  of  human  life  shall  be  Incapable 
of  satisfying  all  the  requirements  for  Initia¬ 
tion  of  a  critical  process.  In  a  multiple  CPU 
environment,  two  or  more  CPU's  shall  be 
required  to  Initiate  such  a  process.  In  a 
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single  CPU  environment,  other/dedicated  hard¬ 
ware  logic  devices  shall  be  AND'ed  with  the  CPU 
commands  to  Initiate  such  a  process. 

6.2.2.2  Critical  data  communicated  between 
CPU's  shall  successfully  pass  data  transmission 
verification  checks  In  both  CPU’s. 

8.2.2. 3  The  results  of  critical  algorithms 
shall  be  verified  prior  to  developmental  and 
tactical  use. 

6.2.2.4  Critical  software  design  and  code 
shall  be  structured  to  enhance  comprehension  of 
decision  logic. 

8.2.2. 5  Software  design  and  code  shall  be 
modular  In  an  effort  to  reduce  logic  errors  and 
Improve  logic  error  detection  and  correction 
functions. 

8.2. 2. 6  Memory  locations  shall  have  unique 
references  (e.g.,  one  and  only  one  name)  to 
prevent  meiwry  useage  conflicts  between 
global/local  variables. 

8.2. 2. 7  The  system  executive  software  shall 
maintain  system  control  at  all  times. 

8.2. 2.8  Hazardous  processes  requiring  criti¬ 
cal  timing  shall  be  automated.  (Refers  to  event 
sequences  which  must  be  tightly  controlled 
and/or  beyond  human  response  time.) 

8.2. 2. 9  Operations  employing  time  limits 
Impacting  system  safety  shall  have  these  time 
limits  Included  In  the  software  decision  logic. 
Both  relative  time  and  mission/absolute  time 
limits  must  be  Included  when  specified  and  used 
as  part  of  the  design. 

8.2.2.10  The  safety-critical  time  limits  in 
the  software  logic  shall  not  be  changeable  by 
an  operator/f light  officer  from  a  console/ 
cockpit. 

8.2.2.11  Upon  detection  of  an  anomaly,  the 
system/weapon  shall  revert  to  a  safe  configura¬ 
tion. 

8.2.2.12  Upon  detection  of  a  critical  anomaly, 
the  software  shall  Inform  the  operator  what 

anomaly  was  detected.  Non-critical  anomalies 
shall  be  recorded  or  reported  by  telemetry  to 
aid  In  system  analysis. 
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8.2.2.13  Upon  detection  of  a  critical  anoaialy, 
the  software  shall  Infora  the  operator  what 
action  was  taken.  System  response  to  non- 
crltlcal  anoaalles  shall  be  available  for  sys¬ 
tem  analysis. 

8.2.2.14  Upon  safing  the  system,  the  software 
shall  Identify  the  resulting  system  configu¬ 
ration  or  status  to  the  operator. 

8.2.2.15  Workaround  procedures  shall  not  be 
allowed  when  reverting  to  a  safe  configuration 
after  the  detection  of  an  anomaly. 

8.2.2.16  Safing  scenarios  for  safety  critical 
hardware  Items  shall  be  designed  Into  the 
logic. 

8.2.2.17  The  software  system  shall  protect 
against  unauthorized  access. 

8.2.2.18  Software- control led  sequences  affect¬ 
ing  safety  shall  require  a  minimum  of  two  Inde¬ 
pendent  procedures  for  Initiation. 

8.2.2.19  There  shall  be  procedures  to  safely 
handle  contingencies. 

8.2.2.20  Interrupt  priorities  and  responses 
shall  be  specifically  defined  and  Implemented 
In  the  software. 

8.2.2.21  The  software  shall  be  Initialized  to 
a  known  and  predictably  safe  state,  from  the 
program  counter  Initial  value  through  program 
execution  to  Initialize  data  mamory  values. 

8.2.2.22  The  software  shall  terminate  to  a 
known  and  predictably  safe  state.  All  settable, 
non-volltlle  devices  and  relays  shall  be  set  to 
a  known,  safe  state  In  anticipation  of  system 
restart  or  random  power  Inputs/outputs. 

8.2.2.23  All  unused  memory  locations  shall  be 
Initialized  to  a  pattern  that  If  executed  as  an 
Instruction  will  cause  the  systM  to  revert  to 
a  known  safe  state.  (For  example, (assuming  a 
2-80  processor)  any  entry  Into  a  pattern  of 
NOP,NOP,JMF,NOP,NOP,JNP,IIOP,NOP....  would  cause 
a  Jump  to  address  0000,  where  a  system  safety/ 
restart  routine  could  reside.) 

8.2.2.24  There  shall  be  provisions  to  protect 
the  accessibility  of  memory  region  Instructions 


and/or  data  dedicated  to  critical  software 
functions. 

8.2.2.25  There  shall  be  provisions  to  protect 
Instruction  types  In  any  program  memory  region 
from  being  used  by  any  except  critical  software 
functions.  (Instructions,  for  example,  which 
can  only  be  used  In  a  supervisor  mode.) 

8.2.2.26  No  software  shall  use  a  STOP  or  HALT 
Instruction  or  cause  a  CPU  WAIT  state.  The  CPU 
must  always  ‘be  executing,  whether  Idle  with 
nothing  to  do  or  actively  processing. 

8.2.2.27  Flags  shall  be  unique  and  shall  be 
single  purpose. 

8.2.2.28  Files  shall  be  unique  and  shall  be 
single  purpose. 

8.2.2.29  CPU's  that  have  simple  Instruction 
sets  are  preferred  to  CPU's  that  offer  exten¬ 
sive  Instruction  variants. 

8.2.2.30  CPU's  that  load  entire  Instructions 
and  data  words  are  preferred  to  CPU's  that 
multiplex  Instruction  and  data  words  In 
n- parts. 

8.2.2.31  CPU's  that  segregate  Instructions  and 
data  memories  In  separate  banks  served  by  sepa¬ 
rate  (and  different  width)  busses  are  preferred 
over  CPU's  that  have  a  single  memory  bus  to 
access  both  Instructions  and  data  from  the  same 
address  space. 

8.2.2.32  A  CPU  that  time-shares  Its  memory 
bus(es)  between  address  and  data  functions 
should  provide  at  least  TBO  complete  clock 
cycles  between  functions  on  each  bus. 

8.2.2.33  Critical  operational  software 
Instructions  must  be  resident  In  non-volatile 
read-only  memory  (ROM).  If  a  safety  kernel  Is 
used.  It  also  must  be  resident  In  ROM. 

8.2.2.34  Data  used  by  critical  software  should 
be  protected  by  error  checking  and  correcting 
(ECO  memory/momory  controller. 

8.2.2.35  Fixed  or  one-time  changing  data  used 
to  vector  critical  software  should  reside  In 
EAROM,  EEROM,  or  similar  latching  memory  for 
retention  permanence.  The  write  control  of 
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such  nenory  shall  be  considered  critical  and 
shall  be  treated  In  the  saae  vein  as  a  poten¬ 
tially  hazardous  event. 

8.2.3  CPU-Hardware/Hardware-CPU  Interfaces 

8. 2. 3.1  A  status  check  of  critical  one-shot 
systea  eleaents  shall  be  aade  prior  to  execut¬ 
ing  a  potentially  hazardous  sequence.  (Safe- 
ara-devlce  (SAD)  status.  Interlock  status, 
etc.) 

8. 2. 3. 2  An  operational  check  of  testable 
critical  systea  eleaents  shall  be  aade  prior  to 
executing  a  potentially  hazardous  sequence. 
(Tiae  clocks,  door  operation,  batteries  up,  CPU 
execution,  uablllcal  disconnected,  etc.) 

8. 2. 3. 3  Upon  coapletlon  of  a  test  where 
safety  Interlocks  were  reaoved,  the  restoration 
of  those  Interlocks  shall  be  verified. 

8. 2. 3. 4  When  software  generates  a  hardware 
coaaand,  a  design  analysis  shall  be  perforaed 
to  deteralne  If  the  coaaand  should  be  continu¬ 
ous  until  reversed  or  only  used/applled  for  a 
discrete  length  of  tiae.  Reason:  Potential 
hazardous  tiaing,  sneak  tiaing,  etc. 

8. 2. 3. 5  Decision  logic  using  registers  which 

obtain  data  values  froa  end  Itea  hardware/ 

software  shall  not  be  based  on  values  of  all 

•ones.* 

8. 2. 3. 6  Decision  logic  using  registers  which 
obtain  data  values  froa  end  Itea  hardware/ 

software  shall  not  be  based  on  values  of  all 

•zeros.* 

8. 2. 3. 7  Decision  logic  using  registers  which 

obtain  data  values  froa  end  Itea  hardware/ 

software  shall  require  a  specific  binary  data 
pattern  of  'ones'  and  'zeroes'  to  reduce  the 

likelihood  of  aalfunctloning  end-ltea  hardware/ 
software  satisfying  the  decision  logic. 

8. 2. 3.8  Separate  *ara*  and  *f1re*  coaaands 

shall  be  required  for  ordnance  Initiation. 

8. 2. 3. 9  Critical  hardware  controlled  by  soft¬ 
ware  shall  be  Initialized  to  a  known  safe 

state. 
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8.2. 3. ID  Unless  specifically  exempted,  Input/ 
output  ports  shall  not  be  used  for  both  criti¬ 
cal  and  noncritical  functions.  Relates  primar¬ 
ily  to  CPU's  with  two  or  more  dedicated 
Input/dedicated,  output/dedicated.  Input- 
output/combination  ports  and  special  I/O 
Instructions  to  access  them. 

8.2.3.11  Critical  Input/output  ports  shall 
have  addresses  sufficiently  different  from 
non-critical  ports  that  a  single  (multiple) 
address  bit  failure  will  not  allow  access  to 
critical  functions  or  ports.  Relates  primarily 
to  CPU's  with  memory-mapped  I/O  but  can  also 
apply  to  CPU's  with  a  single  combination  1/0 
port  and  Instructions  to  access  It. 

8.2.4  Other  Hardware  Factors/Utllltles/Outside 
Influences 

8.2.4. 1  The  system  shall  provide  for  a  fall- 
safe  recovery  from  Inadvertent  Instruction 
jumps. 

8.2. 4.2  The  computer  system  shall  be  Immune  to 
the  effects  of  temporary  power  outages. 

8.2. 4. 3  The  computer  system  shall  be  suffi¬ 
ciently  protected  against  the  harmful  effects 
of  electromagnetic  Interferences. 

8.2. 4. 4  The  computer  system  shall  be  suffi¬ 
ciently  protected  against  the  harmful  effects 
of  electrostatic  Interference. 

8.2.4. 5  There  shall  be  periodic  memory  Integ¬ 
rity  checks  (of  both  program  and  data  memories 
If  separate  or  served  by  different  busses). 

8.2.4. 6  The  Integrity  of  the  Instruction  mem¬ 
ory  RDM  should  be  enhanced  with  an  ECC  memory 
controller  or  a  periodic  software/ hardware 
checksumming  algorithm. 

8.2.4. 7  There  should  be  periodic  data  and 
program  memory  bus  operational  checks. 

6.2. S  (Interrupt)  Operating  System/ut 111  ties 
Software 

8.2. S.l  The  software  shall  discriminate 
between  false  and  valid  Interrupts. 
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.2.5.2  Operating  Sjfste*  (OS)  software,  work* 
Ing  on  a  fixed  stack  size  with  accuaulated 
depth  In  applications  use,  shall  not  get  lost 
in  the  sense  of  overflowing  and  overwriting 
other  prograa  Instructions  or  data  or  In  the 
sense  of  overflowing  and  not  being  able  to 
correctly  return  all  previous  calls. 

8.2.5. 3  Operating  S>steii  software  shall  place 

all  shareable  CPU  resources  on  the  stackfother 
prescribed  neinry  area  before  a  called  Module 
begins  to  execute  with  these  resources.  In 
most  applications,  this  requires  a  full  and 
complete  verification  of  the  compiler  and/or 

assembler  process  tool  to  produce  such  mechine 
code  for  the  source  code  writer.  In  some 

cases,  this  OS  software  Is  coded  once  and 
repllcated/called  from  each  Interrupt  executive 
to  handle  any  and  all  Interrupt  level  software 
requests. 

8. 2. 5. 4  Re-entrant  and  shareable  software 

utilities,  such  as  trigonometric  functions, 
primitives,  etc,  shall  not  overwrite  their 
temporary  scratch  memory  areas  when  they  are 
used  In  several  levels  of  prioritized  Interrupt 
processes. 

8. 2. 5. 5  Re-entrant  and  shareable  software 

utilities  shall  not  Internally  call  another 
utility.  For  example,  the  SIN  function  shall 
not  call  a  SORT  function  and  a  TAN  function 
shall  not  call  a  LOG  function. 

8.2.6  Operator  Interfaces 

The  following  Items  generally  do  not  apply  to 
embedded  weapon  software,  such  as  software 
embedded  In  an  airborne  guided  missile  or  a 
smart  bomb.  The  operator  Interface  Is  external 
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to  the  weapon  Itself.  The  operator  does  have 
control  over  the  weapon  until  the  'pickle' 
button  Is  depressed,  but  from  that  time  on, 
safety  of  the  weapon  operation  rests  entirely 
on  the  internal  and  autonomous  weapon  design. 
Notable  exceptions  would  be  weapons  undergoing 
tests  where  a  command  destruct  function  Is 
provided. 

8.2.6. 1  The  software  shall  require  two  or  more 
operator  responses  for  Initiation  of  any  poten¬ 
tially  hazardous  sequence.  No  hazardous 
sequence  shall  be  Initiated  without  operator 
Intervention  and  that  sequence  shall  not  be 
Initiated  by  a  single  operator  keyboard  entry. 

8.2. 6.2  Operator  Interactions  with  the  soft¬ 
ware  shall  be  concise. 

8.2. 6.3  The  software  shall  provide  for  detec¬ 
tion  of  Improper  sequence  requests  by  the 
operator. 

8.2. 6.4  The  software  shall  provide  for  notifi¬ 
cation  of  Improper  keyboard  entries  by  the 
operator. 

8.2.6. 5  The  software  shall  provide  for  opera¬ 
tor  cancellation  of  current  processing. 

8. 2. 6. 6  Operator  cancellation  of  current  proc¬ 
essing  shall  require  a  single  keystroke  opera¬ 
tor  response. 

8.2. 6.7  Cancellation  of  processing  shall  be 
accomplished  In  a  safe  manner. 

8.2. 6. 8  Any  override  of  a  safety  Interlock 
shall  be  Identified  to  the  test  conductor  via 
display  on  the  test  conductor's  CRT. 
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APPENDIX  A.  SOFTWARE  SAFETY  ANALYSIS 
SPECIFICATION  -  EXAMPLE 

MOTE;  The  followlnfl  Is  strictly  an  EXAMPLE  I 
It  is  MOT  designed  to  be  used  as  written  MOR 
is  It  implied  that  sneak  analysis  Is  the  pre¬ 
ferred  analysis  methodology!  An  actual  soft¬ 
ware  safety  analysis  specification  must  be 
carefully  tailored  based  both  on  the  tech- 
nlque(s)  involved  and  the  system  to  which  it 
is  to  be  applied. 

Purpose.  The  sneak  analysis  technique  described 
herein  establishes  possible  procedure  for  per- 
forming  the  analysis  and  reporting  the  results. 
The  analysis  is  used  to  systematically  Iden¬ 
tify  and  report  sneak  conditions.  Document 
errors  discovered  during  the  sneak  analysis  are 
also  reported. 

Usage.  Sneak  analysis  Is  a  powerful  tool  to 
identify  system  conditions  that  could  degrade 
or  adversely  Impact  mission  safety  or  basic 
equipment  reliability.  It  is  a  topological, 
graphical  technique  that  can  be  applied  to  both 
hardware  and  software.  The  purpose  of  software 
sneak  analysis  is  to  define  logic  control  paths 
which  cause  unwanted  operations  to  occur  or 
which  bypass  desired  operations  without  regard 
to  failures  of  the  hardware  system  to  respond 
as  programed.  After  a  sneak  circuit  analysis 
and  a  software  sneak  analysis  have  been  per¬ 
formed  on  a  system,  the  Interactions  of  the 
hardware  with  the  system  software  can  readily 
be  determined.  The  effect  of  a  control  opera¬ 
tion  that  is  initiated  by  some  hardware  element 
can  be  traced  through  the  hardware  until  It 
enters  the  system  software.  The  logic  flow  can 
then  be  traced  through  the  software  to  deter¬ 
mine  its  ultimate  impact  on  the  system. 
Similarly,  the  logic  sequence  of  a  software- 
initiated  action  can  be  followed  through  the 
software  and  electrical  circuits  until  Its 
eventual  total  system  Impact  can  be  assessed. 
Finally,  the  analysis  should  be  consider ’>d  for 
critical  systems  and  functions  where  ..,cak 
conditions  cannot  be  tolerated,  sneak  condi¬ 
tions  are  suspected,  or  an  unusually  large 
number  of  anomalies  have  been  observed  to  occur 
without  any  reasonable  Justification. 

Applicable  Documents:  (Software  Sneak  documen¬ 
tation  is  pending  and  the  following  documents 
apply  to  hardware  SCA  only.  They  would  need 
tailoring  for  use  on  software  systems.)  The 


following  documents  of  the  Issue  noted  or.  If 
not  noted,  the  Issue  In  effect  as  of  the  date 
of  the  contract  as  shown  In  Department  of 
Defense  Index  of  Specifications  and  Standards 
form  a  part  of  this  specification. 


TABLE  1.  APPLICABLE  DOCUMENTATION 


DOCUMENT  NUMBER 

DOCUMENT  NAME 

1.  N1L-STD-785B 
(15  September  19B0) 

Reliability  Program 

Plan  for  Systems  and 
Equipment 

2.  M1L-STD-781C 
(21  October  1977) 

Reliability  Design 
Qualification  and 
Acceptance  Test 

Standard 

(App.  A,  para  40.7) 

3.  MIL-STD-8B2B 
(30  March  1984) 

System  Safety  Program 
Requirements 

4.  NAVSAEA  TEOOl- 
AA-fiTO-OlO/SCA 

Contracting  and  Manage¬ 
ment  Bulde  for  Sneak 
Circuit  Analysis 

5.  000  5000.40 
(8  July  1980) 

Reliability  and  Main¬ 
tainability  (para  D.2a) 

Requirements:  During  the  full-scale  engineering 
development  and/or  unlimited  production  phase, 
the  contractor  shall  conduct  or  contract  for 
sneak  analysis  of  circuitry/software  critical 
to  mission  success  or  crew  safety.  The  analy¬ 
ses  shall  Identify  latent  paths  which  cause 
unwanted  functions  to  occur  or  which  Inhibit 
desired  functions.  Potential  design  or  equip¬ 
ment  weaknesses  are  to  be  identified  and 
reported.  An  assessment  of  the  system  Impact  1$ 
to  be  provided  for  the  potential  problem  along 
with  a  recommendation  for  corrective  action. 
In  making  these  analyses,  all  components/ 
software  shall  be  assumed  to  be  functioning 
properly.  These  analyses  shall  be  performed  on 
the  actual  code  and  specifications  for  the 
software  to  be  analyzed  during  the  full-scale 
engineering  development  of  later  phases. 
Equivalent  or  design  type  drawings  or  logic 
flows  shall  be  used  during  earlier  development 
phases. 
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The  contractor  shall  present  In  the  proposal  a 
complete  11st  or  description  of  the  functions/ 
circuitry/software  for  which  sneak  analysis  Is 
to  be  conducted.  The  list  of  those  functions/ 
circuits/software  to  be  analyzed  shall  be  pre* 
sented  to  the  procuring  activity  together  with 
the  rationale  for  any  deviations  to  the  speci¬ 
fied  systems. 

The  contractor  shall  specify  the  overall  task 
period  of  performance  along  with  subtask  peri¬ 
ods  of  performance.  Periodic  reviews  or  report 
periods  shall  be  established  to  promote  timely 
transmission  and  consideration  of  contractor 
reports.  A  final  report  documenting  the  task 
and  all  findings  shall  be  prepared.  Including 
the  network  tree  database.  A  final  report  for 
the  baseline  analysis  shall  be  required,  fol¬ 
lowed  at  the  conclusion  of  the  change  analysis 
task  with  a  final  report  documenting  the 
change  analysis  reports. 

The  contractor  shall  Indicate  the  level  of  the 
sneak  analysis  task  In  the  proposal.  The  typi¬ 
cal  software  task  occurs  at  the  Instruction 
level  where  cause  and  effect  relationships  are 
studied  In  detail.  Systems  defined  as  within 
scope  of  the  contracted  effort  should  be  ana¬ 
lyzed  to  the  detail  component  level.  An  Inter¬ 
face  analysis  should  be  performed  for  that 
portion  of  out-of-scope  software  directly 
Interfacing  with  the  1n-$cope  systems. 

Technique.  Four  classical  categories  of  the 
sneak  analysis  technique  shall  be  addressed: 

a.  Sneak  paths,  which  allow  software  logic 
to  flow  along  unsuspected  routes. 

b.  Sneak  timing,  which  causes  functions  to 
be  Inhibited  or  to  occur  unexpectedly  as  a 
result  of  timing  or  function  sequencing. 

c.  Sneak  labels,  which  cause  an  operator 
to  Initiate  Incorrect  stimuli. 

d.  Sneak  Indicators,  which  produce  ambigu¬ 
ous  or  false  displays. 

A  formal  sneak  analysis  shall  Involve:  (1) 
classifying  basic  circuit  or  software  recogni¬ 
tion  patterns  Into  which  the  system  elements 
fall,  (2)  application  of  "clues*  or  sneak 
condition  criteria,  applied  to  these  patterns 
to  iHicover  sneak  conditions,  (3)  assessing  the 


effect  of  the  sneak  conditions  on  system  per¬ 
formance,  (4)  establishing  accept/reject  crite¬ 
ria,  and  (5)  reporting  of  results  to  the 
procuring  activity. 

The  contractor  shall  Identify  latent  flow 
paths,  unexpected  operational  modes,  unneces¬ 
sary  components,  etc..  In  case  of  hardware;  or 
unused  and  Inaccessible  paths.  Improper  branch 
sequencing,  undesirable  loops,  etc.,  in  the 
case  of  software. 

The  contractor  shall  document  the  criteria, 
assumptions,  delineation  of  sneak  paths,  etc., 
of  the  analysis.  The  data  shall  be  maintained 
and  updated  to  reflect  any  changes  In  equipment 
configuration.  If  funded  by  contract. 

Assumptions.  Assumptions  are  made  when  perform¬ 
ing  sneak  analysis  to  establish  the  analysis 
boundaries,  define  terminology,  and  keep  the 
scope  within  cost-effective  bounds. 

TABLE  2.  SOFTWARE  SNEAK  ANALYSIS  ASSUMPTIONS 

A.  THE  SOFTWARE  SPECIFICATION  IS  THE 
DESIGN  INTENT  OF  THE  SOFTWARE. 

B.  THE  ASSEMBLER  OR  COMPILER  DOES  NOT 
INTRODUCE  ERRORS  INTO  THE  SOFTWARE. 

C.  ASSEMBLED  OR  COMPILED  SOFTWARE  IS  FREE 
OF  SYNTAX  ERRORS,  I.E..  HPOGRAPHICAL  ERRORS. 

0.  THE  DATA  PROVIDED  REPRESENT  THE  COM¬ 
PLETE  SOFTWARE  PROGRAM  UNDER  CONSIDERATION. 

E.  HARWARE-INDUCEO  PROBLEMS  ARE  NOT 
CONSIDERED. 


Quality  Assurance  Provisions.  To  Insure  that  a 
valid  sneak  analysis  will  be  accomplished, 
provisions  must  be  established  to  provide 
that:  (I)  all  paths  within  a  system  have  been 
analyzed,  (2)  each  path  Is  directly  traceable 
to  the  network  tree  In  which  It  was  analyzed, 

(3)  each  component/statement  Is  directly  trace¬ 
able  to  the  path  In  which  It  was  analyzed,  and 

(4)  each  component /statement  Is  directly 
traceable  to  the  specific  documentation  used  to 
establish  the  data  base  master  file. 

The  following  provisions  shall  be  used  to  pro¬ 
duce  a  valid  sneak  analysis: 
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1.  Network  trees  analyzed  for  sneak  conditions 
shall  be  traceable  to  the  systea's  source  code. 
T^e  network  trees  shall  contain  all  stateamnts 
used  to  generate  the  tree.  Further,  all  paths 
necessary  to  Initiate  and  complete  a  given 
function  shall  be  shown  or  referenced  on  one 
network  tree. 


2.  Cross-references  listing  data  content  and 
allowing  traceability  of  the  network  trees 
shall  be  furnished. 


3.  All  software  network  trees,  completely 
annotated  to  show  code  represented,  shall  be 
furnished  as  part  of  the  output  of  this  analy¬ 
sis.  These  trees  should  be  In  a  neat  and  under¬ 
standable  format  and  shall  represent  a 
self-contained  data  base  from  which  other 
analyses  (software  fault  tree,  software  hazard) 
may  be  done. 

4.  Each  path  shall  be  Independently  analyzed 
as  to  Its  effects  on  system  operation  and 
records  maintalnes  Indicating  analysis  results. 
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APPENDIX  B.  REQUEST  FOR  PROPOSAL  EXAMPLE 

MOTE;  The  following  Is  strictly  an  EXAMPLE t 
It  is  MOT  designed  to  be  used  as  written  MOM 
Is  It  Implied  that  sneak  analysis  Is  the  pre¬ 
ferred  analysis  methodology!  An  actual  soft¬ 
ware  safetjf  analysis  request  for  proposal  must 
be  carefully  tailored  based  both  on  the  tech- 
nlque(s)  involved  and  the  system  to  which  it 
Is  to  be  applied. 

Sneak  Analysis  Request  for  Proposal  Considera¬ 
tions.  The  basic  requirenents  for  a  procuring 
activity-initiated  sneak  analysis  request  for 
proposal  (RFP)  are  presented  in  this  section. 
The  outline  can  be  tailored  by  the  procuring 
activity  to  suit  a  specific  application.  The 
outline  is  intended  to  be  specific  enough  for 
the  procuring  activity  to  properly  assess  and 
evaluate  contractor  responses.  Evaluation 
criteria  are  also  presented  to  provide  a  basis 
for  evaluation.  The  outline  of  the  sneak  analy¬ 
sis  RFP  and  evaluation  criteria  are  shown  in 
Table  1. 


TABLE 

1.  OUTLINE  OF  A 

SNEAK 

ANALYSIS  RFP  PROPOSAL 

REQUEST  FOR  PROPOSAL 

(RFP)  OUTLINE 

1. 

PROGRAM  NAME 

8. 

DATA  REQUIREMENTS 

2. 

PURPOSE  OF  RFP 

9. 

TASK  DESCRIPTIONS 

3. 

SCOPE  OF  EFFORT 

10. 

DELIVERABLES 

4. 

APPLICABLE 

11. 

MISCELLANEOUS 

SUBSY 

STEMS 

5. 

ANALYSIS  DEPTH 

12. 

FACILITIES  AND 

SECURITY 

6. 

CHANGE  ANALYSIS 

13. 

COST 

OPTION 

7. 

ADDITIONAL 

14. 

TIME  REQUIREMENTS 

ANALYSIS 

EVALUATION  CRITERIA  (EC) 

1.  UN0ERSTAN0IN6  PROBLEM  4.  COST 

2.  RELEVANT  PAST  PERFORMANCE  5.  SCHEDULE 

3.  CAPABILITY  TO  PERFORM 


Request  for  Proposal  Items: 

1.  Program  Name  -  This  is  a  title  of  the  sneak 
analysis  task  which  is  generally  the  program 
name.  The  major  subsystem  equipment  or  software 
name  may  be  added  to  the  title. 


2.  Purpose  -  The  purpose(s)  for  requesting  the 
sneak  analysis  should  be  stated.  The  rationale 
may  be  oriented  toward  problem  identification 
of  design  analysis  at  the  validation  and  full- 
scale  engineering  development  phases  or  problem 
identification  or  change  analysis  in  later 
development  phases.  This  section  should  stipu¬ 
late  the  task  as  being  a  "one-shot*  analysis,  a 
continuing  analysis  with  change  analysis 
included,  or  a  combination  of  sneak  analysis 
with  one  or  more  analysis  techniques.  Combined 
hardware  and  software  sneak  analyses  techniques 
are  to  be  stipulated  as  an  Integrated  analysis 
(system,  interface,  detailed). 

3.  Scope  of  Effort  -  The  task  scope  should 
delineate  task  requirements,  depth  of  analysis, 
system  or  subsystems  included  in  the  analysis, 
period  of  performance,  and  deliverable  end 
products.  The  scoping  paragraphs  may  contain 
Important  notes  or  clauses  from  the  remaining 
RFP  items  described  in  this  section.  Specific 
systems,  subsystems,  or  portions  of  the  soft¬ 
ware  may  be  excluded  from  the  effort  and  listed 
in  this  section.  If  multiple  systems  or  sub¬ 
systems  are  to  be  analyzed  one  at  a  time,  the 
order  and  time  phasing  for  each  subtask  should 
be  specified.  The  responsibility  for  data 
acquisition  should  be  identified  as  a  task  for 
the  procuring  activity,  the  sneak  analysis 
contractor,  or  a  third  party.  When  classified 
systems  are  to  be  analyzed,  security  require¬ 
ments  should  be  specified  for  personnel,  facil¬ 
ities,  documentation  handling  procedures,  and 
computer  processing.  The  task  scope  should 
specify  whether  a  change  analysis  is  Included 
in  the  overall  effort,  and  if  so,  the  number 
and  type  of  acceptable  changes  should  be 
specified. 

4.  Applicable  Subsystems  -  Applicable  software 
is  to  be  accurately  and  completely  Identified 
in  the  RFP.  Figures  and  pictures  may  be  used  to 
clarify  and  bound  the  applicable  areas.  Accu¬ 
racy  is  required  in  this  item  because  cost, 
schedule,  or  problem  identification  limitations 
may  require  analysis  of  only  portions  of  par¬ 
ticular  subsystems  and  whole  subsystems  In 
others.  Whenever  portions  of  primary  functions 
in  the  applicable  subsystems  continue  Into 
equipment  or  software  not  considered  In  scope, 
it  is  necessary  to  provide  Interface  control 
documents,  functional  system  diagrams,  or 
logic-type  diagrams  that  identify  or  depict  the 
remainder  of  the  function. 
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5.  Analj^sls  Depth  -  Analysis  depth  Is  an 
Important  scoping  consideration  because  It  has 
a  direct  bearing  on  cost,  schedule,  and  antlc- 
Iw  ced  results.  The  procuring  activity  should 
specify  the  level  of  the  sneak  analysis 
required  as  system.  Interface  or  detail  level. 
This  RFP  Item  Is  Important  to  the  procuring 
activity  because  It  enables  a  correlation  RFP 
response.  Some  responses  may  cover  the  desig¬ 
nated  software  for  markedly  lower  cost  and 
schedule  time  due  to  performance  of  a  higher 
level  systems  analysis  rather  than  a  more 
detailed  systems  analysis.  The  analysis  depth 
specified  In  the  RFP  must  be  matched  to  the 
level  of  detail  In  the  acquired  documentation. 

6.  Change  Analysis  Option  -  The  Incorporation 
and  analysis  of  software  code  Instruction 
changes  must  be  specified  In  the  RFP  If  desired 
by  the  procuring  activity.  The  change  option 
may  be  limited  to  an  analysis  for  only  the 
proposed  software  design  changes  brought  about 
by  prime  contractor  response  to  sneak  analysis 
reports.  A  more  formal  change  analysis  would 
Include  all  changes  to  a  particular  configura¬ 
tion  baseline.  In  either  case,  the  procuring 
activity  should  specify  the  number  and  type  of 
changes  desired  and  the  change  analysis  period 
of  performance.' 

7.  Additional  Analyses  -  Whenever  sneak  analy¬ 
sis  Is  to  be  performed  In  conjunction  with 
other  analyses,  the  selection  and  phasing  of 
the  tasks  should  be  specified.  Care  should  be 
exercised  In  this  process  to  Insure  that  the 
maximum  benefits  are  achieved  for  each  of  the 
analyses.  Combined  analyses  are  usually  per¬ 
formed  on  highly  criticality  software.  They 
may  also  be  applied  to  areas  which  have  been 
manifesting  anomalies.  Combining  analyses  Is 
also  a  means  of  achieving  cost  reductions. 
Central  to  any  analysis  Is  the  effort  required 
to  establish  the  configuration  on  which  the 
analysis  is  to  be  performed.  A  combined  analy¬ 
sis  effort  requires  the  design  configuration 
building  only  once,  and  this  has  typically  been 
accomplished  by  the  sneak  analysis  task  for 
electrical  and  software  systems.  The  sneak 
analysis  network  tree  approach  provides  a  func¬ 
tional  layout  of  the  system  where  cause  and 
effect  relationships  can  be  Identified  and 
depicted  easily.  While  the  fundamental  premise 
of  sneak  analysis  assumes  no  equipment  or  soft¬ 
ware  failures,  failures  can  be  postulated  at 
any  level  and  their  effects  traced  through  the 


systems  In  the  same  way  as  a  detailed  failure 
mode  and  effects  analysis.  The  network  tree 
data  base  also  serve  as  the  basis  for  other 
analyses,  which  eliminates  duplicate  efforts, 
standardizes  the  configuration,  and  lowers  the 
overall  costs. 

8.  Data  Requirements  -  Analysis  requires  com¬ 
pilable  source  code  listings,  system  block 
diagrams,  high-level  functional  diagrams  and 
program  description  documents.  Including 
requirements  and  specifications.  Also,  :any 
logic  flow  diagrams,  flowcharts,  machine  spe¬ 
cific  procedures,  system  architecture,  and 
program  environment  Information  is  needed  where 
applicable. 

The  procuring  activity  must  assign  the  data 
acquisition  task  responsibility  to  the  prime 
contractor  and  subcontractors  to  the  procuring 
activity  Itself,  or  to  the  performing  sneak 
analysis  contractor.  The  procuring  activity, 
working  through  the  prime  contractor  and  ven¬ 
dors,  has  been  the  customary  designee  for  this 
task.  Allocations  for  the  data  acquisition 
effort  will  be  made  regardless  of  who  is 
selected.  Items  to  be  considered  for  this 
effort  are  the  prime  contractor  and  vendor 
costs  and  delivery  schedules  If  they  are  desig¬ 
nated  for  data  acquisition.  The  procuring 
activity  and  the  sneak  analysis  contractor 
require  funding  to  Identify,  order,  and  possi¬ 
bly  travel  to  acquire  the  documentation. 

The  procuring  activity  should  verify  that  the 
overall  program  contract  has  requirements  for 
prime  contractor,  subcontractor  and  vendor 
deliveries  of  software  code  and  documentation 
which  will  permit  sneak  analysis  to  be  per¬ 
formed  In  a  tlMly  and  cost  effective  manner. 
If  delivery  of  code  documentation  and  code  has 
not  been  contracted  for  In  the  overall  program 
procurement  process,  additional  cost  will  be 
Incurred  by  the  procuring  activity  In  obtaining 
data  for  the  analysis.  Third  party  agreements 
will  also  have  to  be  established  which  Identify 
the  documentation  users,  the  purpose,  data 
handling  procedures,  period  of  usage,  and  final 
disposition  of  the  documentation. 

Documentation  acquisition  must  be  timely  and 
complete  early  In  the  sneak  analysis  task  or 
schedule  Impacts  will  occur.  The  majority  of 
sneak  analysis  tasks  are  under  9  Mnths  In 
duration  which  means  that  the  complete 
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documentation  for  such  a  task  should  be 
received  within  a  month  of  task  Initiation. 
Definite  milestone  dates  Indicating  SO  percent 
and  100  percent  levels  for  data  acquisition 
should  be  stated  In  the  RFP. 

The  RFP  should  specify  when  the  analysis  Is  to 
Include  classified  systems  so  that  special 
handling  procedures  are  Instituted.  Personnel 
availability  with  proper  security  clearance 
levels  must  be  established,  along  with  facility 
clearances.  If  data  processing  Is  to  be  per¬ 
formed  using  classified  data,  then  the  computer 
and  computer  facility  must  have  been  approved 
for  classified  data  processing. 

9.  Task  Descriptions  -  The  RFP  should  stipu¬ 
late  that  the  competing  sneak  analysis  contrac¬ 
tors  provide  a  description  of  the  tasks  they 
are  to  perform  to  Identify  sneak  conditions  In 
software.  The  approach  should  be  systematic, 
thorough,  and  complete.  The  task  description 
should  also  declare  whether  any  automation  aids 
are  contemplated  for  use  In  accomplishing  the 
sneak  analysis  task.  Descriptions  of  the  auto¬ 
mation  aids  should  be  provided  Including  the 
rationale  for  use.  Relevant  points  to  consider 
for  automation  Include: 

a.  Direct  conversion  of  prime  contractor 
manufacturing  data  from  magnetic  tape  (or  other 
suitable  media)  to  acceptable  Input  format  for 
the  sneak  analysis  computer  programs. 

b.  Generation  of  the  network  trees  used  In 
the  analysis  phase. 

c.  Change  analysis. 

10.  Deliverables  -  The  deliverables  of  a  sneak 
analysis  task  should  be  specified  In  the  con¬ 
tractor  proposal,  along  with  concise  descrip¬ 
tions  of  each  Item.  As  a  minimum,  the  specified 
reports  and  the  network  tree  data  base  should 
be  furnished  along  with  any  data  cross  refer¬ 
ences  generated.  As  a  minimum,  the  following 
output  reports  should  be  Included: 

a.  Periodic  Status  Report  -  This  report 
documents  the  progress  of  the  various  sneak 
analysis  subtasks.  Identifies  any  problems 
encountered  In  the  analysis  which  might  Impede 
successful  coaqiletlon  of  the  project,  tabulates 
all  sneak  reports  issued,  and  includes  copies 
of  the  sneak  reports  as  they  arc  Issued.  The 


status  report  Is  the  primary  means  of  conveying 
the  findings  of  the  task  In  a  timely  fashion. 
Requirements  for  either  bi-weekly  or  monthly 
status  reports  should  be  specified.  For  long- 
duration  projects  special  quarterly  reports 
which  summarized  the  activities  of  the  previous 
3  month  period  may  be  required. 

b.  Sneak  Analysis  Reports  -  This  category 
of  reports  Includes  software  sneak  reports, 
software  design  concern  reports,  and  software 
drawing  error  reports.  The  primary  Intent  of 
each  report  Is  to  document  problems  found  In  a 
form  that  Is  understandable,  clear,  concise, 
and  easily  verifiable.  The  paperwork  should 
serve  as  a  link  from  the  sneak  analysis  con¬ 
tractor  to  the  procuring  activity  and  on  to  the 
prime  contractor.  The  sneak  analysis  report 
should  briefly  describe  the  undesirable  condi¬ 
tion  and  reference  re 1 event  documentation. 

c.  Final  Report  -  This  report  summarizes 
the  entire  activities  of  the  sneak  analysis 
task.  The  report  should  Include  the  project 
purpose,  scope,  and  an  overall  evaluation  of 
the  analyzed  sy$tem(s).  A  complete  listing  of 
all  documentation  used  In  the  analysis  should 
be  provided  so  that  the  configurations  for  the 
baseline  system  and  system  changes  can  be 
established.  A  brief  description  of  the  project 
tasks  should  be  Included.  A  tabulation  of  all 
reports  Issued  by  the  sneak  analysis  contractor 
to  the  procuring  activity  should  also  be 
Included,  along  with  copies  of  each  report. 
Any  problems  which  had  an  Impact  on  the  suc¬ 
cessful  completion  of  the  task  according  to  the 
scope  and  terms  of  the  originating  RFP  should 
also  be  documented  In  the  final  report. 

d.  Network  Tree  Data  Base.  All  hier¬ 
archical  network  trees  generated  during  the 
analysis,  drawn  in  a  neat  and  well  annotated 
manner,  showing  the  code  represented  by  the 
tree  and  completely  relatable  to  the  software 
being  analyzed. 

The  three  report  types  Just  presented  are  the 
minimum  deliverables  for  a  sneak  analysis  task. 
If  change  analysis  Is  to  be  performed,  any 
problem  conditions  can  be  reported  sufficiently 
with  the  above  type  reports.  If  a  verification 
of  checklists,  technical  orders  (TOs),  or  other 
military-type  procedure  lists  are  Included 
within  the  scope  of  the  contracted  effort, 
slightly  modified  versions  of  the  sneak 
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analysis  reports  nay  be  desirable.  In  this 
Instance,  the  reports  would  Identify  operator- 
1r...ced  errors,  errors  In  control  sequencing, 
ano  errors  of  Interpretation  and  reaction  to 
equipment  displays.  Additional  reports  gener¬ 
ated  to  document  the  results  of  other  analysis 
techniques  should  also  be  described  and 
Included  In  the  final  report.  The  final  report 
could  also  be  used  to  Implement  the  recommenda¬ 
tion  to  measure  sneak  analysis  effectiveness. 

11.  Hlscellaneous  -  Other  uses  of  the  data  base 
should  be  reported  separately.  The  requirements 
for  the  sneak  analysis  contractor  over  and 
above  the  baseline  analysis  should  be  speci¬ 
fied.  This  may  Include,  but  not  be  limited  to, 
the  following: 

a.  Additional  analyses,  such  as  failure 
mode  and  effects  analysis,  fault  tree  analysis, 
and  change  analysis. 

b.  Data  acquisition  and  travel. 

c.  Program  review  support  to  provide  liai¬ 
son  and  Inputs  for  milestone  events  such  as 
PDR,  COR,  first  flight,  or  scheduled  tests. 

d.  Computer  tool  development,  possibly  In 
the  area  of  converting  prime  contractor  data  to 
a  format  usable  In  the  analysis  phase. 

e.  Classified  data  handling. 

12.  Facilities  and  Security  -  Facilities  and 
security  requirements  should  be  a  part  of  the 
RFP,  even  when  classified  data  systems  are  not 
Involved.  This  feature  protects  the  propri¬ 
etary  rights.  If  any,  of  the  software  owner. 
The  entire  contractor  facility  or  some  desig¬ 
nated  portion  thereof  should  be  cleared  to 
handle  the  highest  level  documentation  comtem- 
plated  for  use  by  the  sneak  analysis  contrac¬ 
tor.  Personnel  should  have  at  least 
corresponding  security  clearances.  This 
Includes  direct  management,  engineers  and  soft¬ 
ware  analysts,  clerks,  secretaries,  aides,  and 
any  other  personnel  participating  In  the  clas¬ 
sified  portion  of  the  ana'ysis.  If  any  portion 
of  the  task  Is  computer-aided,  then  the  person¬ 
nel,  computer,  and  computer  facility  must  also 
be  cleared.  Disposition  requirements  to  return 
or  destroy  acquired  documentation  .  and  sneak 
analysis  contractor- generated  reports  must  be 
speciflad. 


13.  Cost  -  Cost  breakouts  for  the  various  sneak 
analysis  tasks  will  normally  be  a  separate 
report  or  volume  from  the  RFP  to  allow  an 
Impartial  evaluation  of  the  technical  portion 
of  the  RFP.  Cost  factors  Include  analysis  per¬ 
sonnel,  computer  processing,  classified  data 
handling,  data  acquisition,  travel,  performance 
of  other  analyses,  and  computer  program  devel¬ 
opment  (If  any). 

14.  Time  Requirements  -  The  time  requirements 
(If  any)  of  the  procuring  activity  should  be 
stated  In  the  RFP.  Dates  for  support  of  CDR, 
first  flight,  or  major  systems  tests  have  a 
direct  bearing  on  the  tasks  and  sequences  of 
tasks  performed  by  the  sneak  analysis  contrac¬ 
tor.  If  the  analysis  Is  'one-shot*  and  scoped 
to  a  single  system  or  portion  of  a  single  sys¬ 
tem,  then  the  task  approach  Is  fairly  direct. 
Otherwise,  multiple  systems  analysis  or  com¬ 
bined  analyses  will  require  the  contractor  to 
prioritize  the  systems  and  the  tasks  within 
each  system. 


Evaluation  criteria  Items: 


1.  Understanding  of  the  task  -  Understanding 
of  the  task  Is  an  important  evaluation  crite¬ 
rion  to  Judge  sneak  analysis  proposals.  The 
evaluation  criterion  looks  not  only  for  an 
understanding  of  the  contractor's  sneak  analy¬ 
sis  process  and  task  relationships  but  also  the 
need  and  use  of  the  analysis  to  satisfy  the 
procuring  activity's  requirements  In  a  timely 
and  cost-effective  manner. 

The  task  process  may  be  different  from  contrac¬ 
tor  to  contractor  but  will  probably  progress 
according  to  the  following  order: 

a.  Data  Acquisition 

(1)  Identify  and  acquire  data  If  so 

tasked. 

(2)  Log  all  documentation  received. 

(3)  Review  all  documentation  for  com¬ 
pleteness  and  correct  level  of  detail. 

(4)  Identify  missing  and  required 
documentation. 
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b.  Preanalysis 

(1)  Identify  functions  In  the 
docuiaentatlon. 

(2)  Verify  systen  Interconnections. 

(3)  Exclude  all  areas  of  docunentatlon 
out  of  scope  for  the  effort. 

(4)  Review  adequacy  of  Interface 
equlpuent  and/or  software  docuawntatlon. 

c.  Partitioning 

(1)  Subdivide  or  software  by  functions 
or  structure. 

(2)  Annotate  docuawntatlon  for  subse¬ 
quent  encoding  task. 

d.  Encoding  (only  If  coaputer  processing 
Is  used) 

(1)  Convert  detailed  source  code  to 
coaputer  foraat. 

(2)  Autoaate  conversion  process. 

(3)  Verify  data  aaster  files  reflect 
actual  systea  configuration. 

e.  Coaputer  Processing 

(1)  Edit  and  analyze  all  user  Inputs. 

(2)  Connect  all  and  software  code  (and 
circuit  segaents  If  appropriate.) 

(3)  Produce  hardcopy  plots  of  systea 
network  trees. 

f.  Network  Tree  Generation 

(1)  Manually  develop  network  trees  If 
no  autoaatlon  aids  are  used. 

(2)  Annotate  all  functional  remarks  on 
network  trees. 

(3)  Annotate  all  cross-references  on 
network  trees. 

(4)  Identify  and  annotate  relevant 
descriptive  documentation. 


(5)  Annotate  Interface  Information  for 
out-of-scope  systems. 

g.  Analysis 

(1)  Identify  topographs  (software 
patterns)  in  network  trees. 

(2)  Apply  'clues*  for  each  topograph. 

(3)  Compare  network  trees  to  func¬ 
tional  systea  flows. 

(4)  Compare  network  trees  to  Interface 
control  documents. 

(5)  Compare  network  trees  to  procedure 
checklists. 

(6)  Perform  timing  analyses  where 
required  (l.c..  Interrupt  and  data  availability 
analysis). 

h.  Problem  Reporting 

(1)  Assess  problem  categorization 
(documentation,  design,  sneak). 

(2)  Identify  relevant  documentation. 

(3)  Describe  problem. 

(4)  Determine  systea  Impact. 

(5)  Provide  sketch  of  systea  Illus¬ 
trating  problem. 

I.  Status  Reporting 

(1)  Provide  periodic  status  reports 
(bi-weekly  or  monthly)  and  contract  funds 
status  reports  (or  equivalent)  providing  ’dol¬ 
lar*  Information. 

(2)  Provide  quarterly  status  reports. 
If  required. 

(3)  Include  all  reports  Issued  during 
the  period. 

(4)  Tabulate  and  Identify  report 
dispositions. 

J.  Change  Data  Receipt  (If  change  analysis 
option  Is  Included). 
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(1)  Acquire  proposed  and/or  leple- 
Mented  system  changes. 

(2)  Log  all  documentation  received. 

(3)  Group  changes  by  function  or  con¬ 
figuration  control  board  package  numbers. 

k.  Change  Data  Incorporation 

(1)  Determine  extent  of  change 

package. 

(2)  Update  network  trees. 

l.  Change  Data  Analysis 

(1)  Reanalyze  all  changed  network 

trees. 

(2)  Reanalyze  all  changed  network 
trees  affected  by  the  changed  network  trees. 

(3)  Rerun  timing  analyses.  If 
necessary. 

(4)  Problem  reporting  Is  the  same  as 
baseline  analysis. 

m.  Final  Report 

(1)  Summarize  task  purpose  and  scope. 

(2)  Describe  analysis  technique. 

(3)  Provide  composite  listing  of  all 
documentation. 

(4)  Provide  tabulation  of  all  reports 
and  dispositions. 

(5)  Provide  copies  of  all  reports. 

(6)  Provide  copies  of  all  reports. 

(7)  Provide  network  tree  data  base  and 
data  cross  references. 

2.  Relevant  Past  Performance  -  Actual  perfor¬ 
mance,  along  with  an  assessment  of  that  perfor¬ 
mance,  should  be  demonstrated  and  presented  In 
the  contractor's  proposal.  The  distinction 
between  actual  performance  and  performance 
capability  needs  to  be  Identified  and  evaleated 
In  the  contractor's  response.  To  adequately 


evaluate  responses,  the  contractor  should  be 
required  to  provide  task  synopses  similar  to 
those  required  by  the  application  guidelines 
procurement  and.  In  addition,  provide,  upon 
request,  copies  of  final  reports  for  procuring 
activity  Inspection.  Resumes  of  key  personnel 
should  also  be  provided.  Emphasis  should  be 
placed  on  showing  experience  In  similar 
programs. 

3.  Capability  to  Perform  -  Capability  to  per¬ 
form  sneak  analysis  Is  the  evaluation  criterion 
which  will  be  the  most  difficult  to  assess. 
Different  approaches  will  be  offered  In  com¬ 
petitive  proposals  by  prospective  contractors. 
Some  may  Include  the  formal  sneak  analysis 
process,  variations  to  the  process,  or  substi¬ 
tution  of  other  analysis  techniques  to  achieve 
the  same  end  results.  As  a  minimum,  the  capa¬ 
bility  to  perform  the  basic  tasks  listed  In 
Item  1  would  be  a  prerequisite  for  further 
proposal  evaluation.  Some  of  the  main  task 
headings  may  change,  but  the  overall  tasks 
should  be  equivalent.  Current  automation  aids 
and  descriptions  of  their  Intended  use  should 
certainly  strengthen  the  evaluation  rating  In 
the  capability  to  perform  criteria. 

4.  Cost  -  Line  Item  costs  for  the  basic  analy¬ 
sis,  change  analysis,  and  other  analyses  should 
be  separately  reported  in  the  proposal.  Costs 
for  personnel,  management,  and  clerical  support 
should  be  delineated,  as  well  as  computer  proc¬ 
essing  costs,  travel  costs,  and  any  other  mis¬ 
cellaneous  cost  Items.  In  general,  the  greater 
number  of  executable  Instructions  In  the 
software,  the  greater  the  sneak  analysis  cost. 
However,  cost  needs  to  be  evaluated  against 
proposed  depth  of  analysis  and  against  the 
quality  of  the  code.  Hell  structured,  modular¬ 
ized,  and  will  documented  code  Is  cheaper  to 
analyze. 

5.  Schedule  -  Contractor  schedules  should  be 
evaluated  for  the  proper  sequencing  and  dura¬ 
tion  of  tasks.  They  should  Identify  all  major 
task  functions  and  project  milestones.  Since 
data  Kquisitlon  Is  very  critical,  early  mile¬ 
stones  for  data  receipt  are  an  absolute  neces¬ 
sity.  Network  tree  construction  can  either  be 
shown  as  one  complete  task  of  relatively  short 
duration  In  the  first  half  of  the  project  or  as 
a  continuing  process  throughout  most  of  the 
period  of  performance.  Either  approach  is 
acceptable.  Analysis  Is  the  main  task  element 
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of  the  procureaent.  The  longest  duration  task 
should  be  the  analysis,  but  the  schedule  dura¬ 
tion  nay  not  Indicate  such  eaphasls. 


The  contractor  schedule  should  also  Include 
support  of  reviews,  other  analysis  technique 
sequencing  and  duration,  change  analysis  If 
selected,  and  final  report  preparation  and 


delivery.  If  classified  or  proprietary  data; 
are  used,  there  should  be  a  final  data  disposi¬ 
tion  task  Included. 

Contract  Selection:  Selection  of  the  type  of 
contract  desired  for  the  sneak  analysis  pro- 
cureaent  Is  prlaarlly  the  option  of  the  pro¬ 
curing  activity  and  should  be  stipulated  In  the 
RFP. 
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APPENDIX  C.  STATEMENT  OF  WORK  EXAMPLE 

t.uTE;  The  following  Is  strictly  an  EXAMPLEl 
It  Is  MOT  designed  to  be  used  as  written  MOR 
Is  It  Implied  that  sneak  analysis  Is  the  pre* 
ferred  analysis  wethodolofly I  An  actual  soft¬ 
ware  safety  analysis  stateaent  of  work  must  be 
carefully  tailored  based  both  on  the  tech- 
nlque(s)  involved  and  the  system  to  which  It 
Is  to  be  applied. 

Tailoring  Statement  of  Work  Requirements.  The 
process  for  tailoring  sneak  analysis  statement 
of  work  requirements  to  acquisitions  of  various 
types  1$  shown  In  generalized  form  In  Figure  1. 
The  process  assumes  that  an  assessment  of 
specification  requirements  and  application 
guidelines  resulted  In  a  decision  to  perform 
the  sneak  analysis  task.  The  need  and  the 
rationale  for  the  task  are  thus  established. 
The  process  flow  Is  now  directed  toward  deter¬ 
mining  how  the  procurement  Is  to  be 
Implemented. 

Tailor  Process;  The  process  flow  shown  will  be 
presented  as  a  step-by-step  description  of  each 
function  or  decision  block.  The  blocks  are 
numbered  to  clarify  the  path  direction  within 
the  decision  tree. 

1.  Identify  Analysis  Areas  -  The  process 
begins  In  block  1  with  an  Identification  of 
relevant  systems  or  subsystems.  On  the  Initial 
pass,  all  software  within  each  of  the  desig¬ 
nated  systems  may  be  scoped  to  determine  over¬ 
all  rough  order  of  magnitude  costs. 

2.  Estimate  System  Size  -  Block  2  requires  an 
estimation  of  the  number  of  Instructions  In  the 
software  system.  Typical  systems  are  composed 
of  high-order  languages,  assembly  languages, 
and  machine  code.  Each  Instruction  can  be 
translated  Into  an  equivalent  number  of  assem¬ 
bly  language  Instructions. 

3.  Compute  Cost  -  Based  on  the  data  from  Items 
1  &  2  compute  rough  order  of  magnitude  costs. 
Software  quality  and  languages  Involved  will 
greatly  Influence  potential  costs. 

4.  Acceptable  Cost  Range  -  The  derived  rough 
order  of  magnitude  cost  of  the  sneak  analysis 
task  Is  compared  to  the  budget  levels  allocated 
in  the  original  program  reliability  plan.  If 
anticipated  costs  are  within  the  budgeted 


level,  the  procuring  activity  may  begin  the 
procurement  process  by  proceeding  to  the  func¬ 
tion  In  block  8  of  Figure  1.  However,  since 
the  original  estimate  was  a  rough  order  of 
magnitude.  It  may  be  necessary  to  perform  a 
more  detailed  estimate  of  costs  to  achieve 
higher  confidence  in  the  cost  figures. 

If  the  task  cost  significantly  exceeds  the 
allocated  analysis  cost,  additional  decisions 
must  be  made  by  considering  reduction  of  analy¬ 
sis  scope  or  combining  sneak  analysis  with 
another  analysis. 

5.  System  Scope  Reduction  -  If  the  rough  order 
of  magnitude  estimate  exceeded  the  planned  task 
allocation,  a  critical  analysis  of  the  desig¬ 
nated  systems  should  be  performed  to  Isolate 
the  desired  functions.  In  effect,  the  task 
effort  should  be  scoped  from  the  overall  system 
level  to  the  subsystem  level  and  possibly  even 
to  the  Instruction  level.  Noncritical  func¬ 
tions  should  be  eliminated  and  a  new  scope  of 
effort  determined.  The  reduced  task  scope  may 
then  be  evaluated  against  the  original  state¬ 
ment  of  need  and  costs  recomputed  by  entry  to 
block  2,  Process  cycling  through  scope  reduc¬ 
tions  and  cost  computations  may  occur  until 
desired  task  cost  levels  are  achieved. 

NOTE  *  The  procuring  activity  could  request 
contingency  funds  to  supplement  the  original 
task  allccc-*c.i».  Pr'gnr  r—tlr^cncy  funds 
are  those  dollars  not  previously  allocated  to 
other  analyses.  Sufficient  budget  could  then 
be  obtained,  and  the  process  flow  could  proceed 
to  block  8. 

6.  Combine  Analyses  -  If  It  Is  not  possible  to 
reduce  the  number  of  functions  scoped  for  the 
analysis  task,  the  procuring  activity  should 
consider  combining  sneak  analysis  with  other 
analysis  tasks.  The  overall  cost  of  performing 
sneak  analysis  with  specific  analyses,  such  as 
failure  mode  and  effects  analysis  and  fault 
tree  analysis.  Is  lower  than  performing  all 
three  tasks  separately.  In  this  way,  lower- 
overall  budget  expenditures  can  be  obtained  for 
the  combined  tasks.  The  resulting  allocations 
should  be  sufficient  for  the  combined  tasks.  If 
the  resulting  budget  allocation  Is  sufficient, 
proceed  to  block  8;  otherwise  the  sneak  analy¬ 
sis  task  must  be  deferred  until  supplemental 
funds  are  available  or  the  procurement  can¬ 
celed.  An  option  is  avalla'-'le  to  the  procuring 
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activity  that  rtaoves  the  requireaent  for  an 
Interface  sneak  analysis.  Very  early  in  the 
prograa  developaent  phase  (concept  or  valida¬ 
tion  phase)  this  aay  be  a  viable  alternative. 
Fron  the  full-scale  development  phase  and  later 
phases,  the  analysis  should  be  at  the  detailed 
level  to  obtain  significant  results. 

7.  Defer  Procureaent  -  If  this  task  decision 
block  Is  reached,  a  reconsideration  of  ration¬ 
ale  or  statement  of  need  should  be  made.  If  the 
decision  1$  made  to  defer  the  task  at  the  ear¬ 
liest  available  time.  The  cost  to  Identify 
problems,  correct  design,  and  Implement 
changes  Increases  dramatically  when  problems 
are  detected  In  later  project  development 
phases. 

8.  Contract  Selection  -  After  the  sneak  analy¬ 
sis  task  Is  properly  scoped  and  program  funds 
are  allocated,  the  next  function  to  be  per¬ 
formed  Is  selection  of  the  type  of  contract  and 
statement  of  work.  The  selection  of  the  proper 
statement  of  work  Is  dependent  on  the  software 
composition  and  the  addition  of  other  task 
analyses. 

9.  Competitive  Procurement  -  The  decision  to 
Issue  a  sole- source  procurement  or  a  competi¬ 
tive-bid  procurement  can  probably  be  made  at  an 
earlier  time  In  the  process  flow.  If  sole 
source  selection  Is  desired,  proceed  to  block 
13  of  the  process  flow.  If  a  competitive-bid 
procurement  Is  selected,  the  decision  should  be 
made  earlier  In  the  development  flow  to  over¬ 
come  the  attendant  delay  In  the  project  Initia¬ 
tion  schedule  until  contract  award. 

10.  Issue  RFP  -  The  bid  package  should  then  be 
circulated  and  announced  In  publications  such 
as  Commerce  Business  Dally. 

11.  Evaluate  Responses  -  Evaluation  criteria 
considerations  were  presented  earlier  and  may 
be  used  as  the  basis  for  evaluating  con¬ 
tractor  responses.  Care  should  be  taken  not 
to  bias  In  favor  of  any  one  methodology,  so 
long  as  a  topological/graphical  approach  Is 
maintained. 

12.  Contract  Award  -  Contract  award  to  the 
winning  bidder  Is  the  final  step  In  the  com¬ 
petitive  procurement  process  and  represents  the 
Initiation  of  the  sneak  analysis  task. 


Figure  1.  Tailoring  Statement  of  Work  Require¬ 
ments 

STATEMENT  DF  WORK  FOR  SOFTWARE 

1.  GENERAL 

A  software  sneak  analysis  shall  be  performed  on 

the _ ^system.  The  analysis 

shall  be  performed  using  topological/graphical 
techniques  as  referenced  In  section  3. 4. 2. 2. 
This  analysis  shall  Identify  data  paths  and 
logic  conditions  that  can  cause  an  unwanted 
function  to  occur  or  Inhibit  a  desired  func¬ 
tion  without  a  hardware  failure.  Recommenda¬ 
tions  for  corrective  action  to  eliminate  these 
conditions  shall  be  provided.  Also,  document 
errors  and  areas  of  design  concern  discovered 
during  the  analysis  shall  be  reported. 

2.  SCOPE 

The  software  sneak  analysis  shall  cover 
the  software  programs  for  use  by  the 

_  system  computer (s).  The 

software  shall  be  analyzed  at  the  executable 
code/instruction  level.  The  software  program  1$ 
coded  In _ , 

3.  CHANGE  ANALYSIS  (DPTIDNAL) 

The  analysis  shall  Include  changes  due  to  cor¬ 
rective  action  taken  to  eliminate  sneak  analy¬ 
sis  Identified  problems  received  prior  to 

_ ,  19  .  The  change  analysis 

shall  be  limited  to  a  total  equal  to _ per 

cent  of  the  baseline  design  data  base  as  estab¬ 
lished  by  actual  count  of  software  Instructions 
added,  deleted,  or  revised  due  to  corrective 
changes.  Wherever  possible,  all  changes  shall 
be  submitted  by  copies  of  the  completed  soft¬ 
ware  problem/change  reports,  copies  of  the 
revised  data  tapes  or  card  decks,  and  listings. 

4.  TASK  DESCRIPTIONS 

Specific  tasks  to  be  performed  as  part  of  this 
analysis  contract  shall  consist  of  the 
following: 

4.1  Receive  and  set  up  files  for  the  software 
program  and  any  design  and  program  documenta¬ 
tion  defining  the  operation  and  functions  of 
the  software  to  be  analyzed. 
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4.2  Develop  a  software  network  tree  data  base, 

•  .3  Perform  a  sneak  analysis  on  the  resulting 
software  network  trees  to  Identify  potential 
sneak  conditions,  such  as: 

4.3.1  Sneak  paths,  which  may  allow  data  or 
logic  to  flow  along  an  unexpected  route. 

4.3.2  Sneak  timing,  which  may  cause  data  or 
logic  to  flow  or  to  Inhibit  a  function  at  an 
unexpected  time. 

4.3.3  Sneak  Indications,  which  may  cause  an 
ambiguous  or  false  display  of  system  operating 
conditions. 

4.3.4  Sneak  labels,  which  may  cause  Incorrect 
stimuli  to  be  Initiated. 

5.  REPORTS 

Reports  will  be  submitted  In  accordance  with 
the  contract  CORL, 

5.1  Prepare  sneak  software  reports  (SSfts)  on 

all  sneak  conditions  found.  Each  report  shall 
describe  the  sneak  condition  In  detail.  The  SSR 
shall  Include  a  listing  of  the  suspect  software 
Instructions  where  appropriate.  Recommenda¬ 
tions  for  appropriate  corrective  action  shall 
be  given  along  with  reference  to  supporting 
documentation.  The  report  forms  Include  a 
section  for  the  customer  to  Indicate  the  action 
taken  to  resolve  the  condition  being  reported. 
All  reports  shall  be  appropriately  dated, 
titled,  and  numbered  for  Indexing  and 

tracking. 

5.2  Prepare  software  design  concern  reports 
(SOCRs)  to  describe  certain  Items  of  concern 
with  specific  design  Implementation.  The  condi¬ 
tions  to  be  reported  Include: 

5.2.1  Questionable  design  practices. 

5.2.2  Unnecessary  software  Instruction. 


5.2.3  Unused  software  Instructions. 

5.2.4  Specifications  not  met  or  not  clear. 

5.3  Prepare  software  document  error  reports 
(SOERs)  on  disci  epancles  found  In  the  Input 
data  for  the  analysis.  Each  report  shall 
identify  the  discrepant  document  and  explain 
the  error  relative  to  referenced  supporting 
documentation. 

5.4  Prepare  and  submit  activity  reports  to 
describe  the  work  accomplished  during  the 
reporting  period.  The  reports  will  Include 
analysis  progress,  problems,  recomctendatlons, 
and  results  of  meetings.  The  reports  shall  be 
submitted  In  accordance  with  the  contract  CORL. 
The  SSRs,  SOCr.s,  and  SOERs  generated  during  the 
reporting  period  shall  be  attached.  A  tabula¬ 
tion  of  all  previously  submitted  reports  (SSR, 
SOCR,  and  SDER),  Including  status,  shall  oc 
attached  to  each  activity  report. 

5.5  Perform  analysis  of  software  changes, 
provided  a  change  analysis  Is  elected,  and 
submit  appropriate  reports. 

5. fi  Prepare  and  submit  a  final  report  contain¬ 
ing  a  summary  of  the  analysis  effort.  Including 
the  general  analysis  method  used,  the  extent  of 
the  analysis,  conclusions  drawn,  and  recommen¬ 
dations  based  on  the  analysis.  All  SSRs, 
SOCRs,  and  SOERs  written  shall  be  Included  as 
well  as  the  completely  annotated  network  tree- 
data  base.  One  report  shall  be  prepared  at  the 
completion  of  the  baseline  analysis,  and  1f  a 
change  analysis  Is  performed,  the  report  shall 
be  revised  to  Include  any  additional  reports 
resulting  from  the  change  analysis. 

6.  DATA  REQUIREMENTS 

The  analysis  will  be  based  on  the  source  list¬ 
ing  and  source  code  which  should  be  pro  vide  l 
In  a  machine  readable  format.  If  the  cualysis 
is  to  be  based  on  a  hIgh-order  language,  the^ 
the  source  program  listing,  high-order  sourc 
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code,  and  an  asseadiled  program  listing  should 
be  provided.  All  reference  manuals  for  the 
computer,  cross-assembler,  language,  and  oper¬ 
ating  system  should  be  made  available.  Also, 
time/cost  may  be  saved  If  other  program  docu¬ 
mentation  be  provided,  such  as  module  descrip¬ 
tions,  flow  diagrams  and  data  structure 
definitions,  so  that  the  potential  system  Im¬ 
pact  for  problems  found  can  be  more  accurately 
assessed.  The  above  data  will  be  fur¬ 
nished  _ .  All  data  must  be  deliv¬ 
ered  by  _  to  enable  a  timely  and  accurate 

analysis.  Delay  In  receipt  of  data  will  result 
In  a  day-for-day  slide  In  the  schedule,  and  the 
contract  price  shall  be  equitably  adjusted  to 
reflect  additional  costs.  If  any. 


7.  PERIOD  OF  PERFORHANCE 


The  period  of  performance  for  the  sneak  analy¬ 
sis  of  the  _ 

system  shall  be  months  after  receipt  of  Input 
data  necessary  to  establish  the  configuration 
as  defined  In  paragraph  2,  SCOPE.  Change 
analysis  shall  be  performed  on  all  previously 
described  changes  received  prior  to 

_ ,  19 _ ,  and  the  final  report 

shall  be  submitted  by _ ,  19 _ ,  pro¬ 

vided  the  contractor  has  acknowledged  all 
reports  by  having  signed  each  report  and 
stated  the  action  taken  to  correct  the  reported 
problem. 


